The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

THE PSION SIBO HARDWARE DEVELOPMENT KIT

Version 1.00

May 26 1995

Revision 1.00 Page i

The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

(c) Copyright Psion PLC 1990-93

All rights reserved. This manual and the programs referred to herein are copyrighted works of Psion PLC, London, England. Reproduction in whole or part, including utilisation in machines capable of reproduction or retrieval, without express written permission of Psion PLC, is prohibited. Reverse engineering is also prohibited.

The information in this document is subject to change without notice.

Psion and the Psion logo are registered trademarks, and Psion, Psion MC, Psion HC, Psion Series 3, Psion Series 3a and Psion Workabout are trademarks of Psion PLC.

TopSpeed is a registered trademark of Clarion Software Corporation. Intel 8086 and 80286 are registered trademarks of Intel Corporation. IBM, IBM XT and IBM AT are registered trademarks of International Business Machines Corp. Microsoft and MS-DOS are registered trademarks of Microsoft Corporation. Apple and Macintosh are registered trademarks of Digital Equipment Corporation. Brief is a registered trademark of Underware Inc. Psion PLC acknowledges that some other names referred to are registered trademarks.

Revision 1.00 Page ii

The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

Contents

De IMGrOMUCUON sec ioiciescccetisshicattxstcathaslicatixssdcstenslacatenstecatenslicatinssdesvenslacevinswdvatensldcsvisatibiteislacibedse

2. System Overview..........scccccscssccssssscscsscsseccsscssecssccsesssscssesssscsssesscssesssssesssscssssssscssssssscsessssesesseeees

3. Hardware Overview .........sssccssssssssssscssscssscsssssssesssesssesssesssesssssssssessscssscsssessesssesssnssseesscseoeeees The Psion SIBO serial protocol .... Psion ASICs and what they do.. Interrupts . The current range of Psion periphera

4. The Psion SIBO Serial Protocol . Hardware Interface ... The Physical layer . The Transport layer ..

5. Mechanical Overview ...........sscssscsssssrscsssssessscessecssessessssesseessessscesssessesscssssssscsssessccssesssessosees LD The Psion Series 3/3a range ... The Psion Workabout The Psion HC range

6. ASIC 4......... ASIC4 Addressing and Modes Reset and configuration ASIC4 Pin-out

7. ASIC 5.......scesee ASICS Mode Reset and configuration ASICS Pin-out

8. Example Peripheralls................cccssccssssssssssssseccsscscccssssscsssscccesssscscesssssesssscsssssssssesscsssssscsseeesess OO The ASIC4 Example Interface Board.. The Psion 3-Link

9. Device Driver Overview...........cccsrsercesssserscersserecssecssesscesssesesssessssessesssesscsscssscsssssssesssessosees OT Introduction Device Names and Channel: Loadable Logical Device Driver Structure Mandatory LDD Functions ............... Interrupts and Interrupt Service Routines at Loadable Physical Device Driver Structure... ccscecesesesseesssesssesesssesesesescseseseenenesesesesesesenenesseesesesusueasaeaeseeessecacaeaeaeenenssesecasaseeeeeneeeeeaeaes

10. ASIC4/ASIC5 Based Device Drivers

Introduction SIBO Hardware Expansion Channels Talking to ASIC4.. ASIC4 Registers Talking to ASICS .. ASICS Registers... Communicating with ASIC4 Sending and Receiving data using ASIC4. Obtaining and using a channel... Controlling ASICS's UART Hold and Resumes. Example Device Driver:

11. An Example Device Driver for ASIC4: A4EXIF.LDD..

Introduction

oo TO eR UU RS gs pad

Mandatory LDD Function: The Non-Mandatory LDD Functions..........cceee The handling of synchronous and asynchronous I/O Interrupts and Interrupt Service Routines Other important local device driver functions Structures and Include files «0... cee

12. An Example Device Driver for ASIC5: SYS$AS5.PDD.............ssssssssssssssessessessssesscsessessesseee 77

Introduction The LDD-PDD interface.

13. Debugging and Testing Device Drivers Introduction .... Debugging Techniqu Further Testing Strategies ae Memory Lestitng seiscs lech easch oiece siscn Sates losecdestecwcsautsse sean tosevaleslosedtracepudtesiiensdertoanioenteoisebeensse bait es ieettaus adanus teats a a tanta eae

APPENDIX: Source Code Files.. A4EXIF.ASM oo SYS$AS5.ASM .... 102 Assembler Macros. 1S

Revision 1.00

Page iii

The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

1. INTRODUCTION

This document is intended to provide guidance to anyone wishing to construct peripherals for the Psion SIBO (sixteen bit organiser) range of computers. It describes in detail all aspects of Psion peripheral hardware development and the structure of the software required to drive such peripherals. It is the aim of this document to aid third party development engineers in producing production ready peripherals for any of the following Psion products: Series 3/3a, Workabout, HC and HCDOS. Mechanical and plastic moulding information and information on how to develop production test equipment is therefore also included. The emphasis throughout is on the two key Psion peripheral chips ASIC4 and ASIC5. Detailed information regarding their functionality is provided. The structure of Psion hardware device drivers is examined both in general outline and then with regard to two specific examples whose source code is provided in the appendix to this document. It has been assumed that the reader has some knowledge of a Psion computer such as the Series 3/3a and an understanding of how such a machine is programmed. A good understanding of electronics, the C programming language and 8086 assembler is also assumed.

Due to the continuous nature of development, information in this manual may change without notice.

Developers are advised to contact Psion Support to confirm critical details prior to committing products to manufacture.

Revision 1.00 Page | of 115 pages

The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

2. SYSTEM OVERVIEW

All present Psion computers are based around the proprietary SIBO architecture. A SIBO machine is a battery-powered, 8086-based, computer system. SIBO stands for SIxteen Bit Organiser. The architecture has been designed with the size, weight and power consumption of computers designed for the portable environment in mind. The key components of the SIBO architecture are:

e —_ An 8086 class processor .

e A sophisticated power management system that selectively powers subsystems under software control.

e Asynchronous, high speed, serial protocol (the Psion SIBO serial interface) for communication between a machine and its peripherals.

e —_ Solid State Disks (SSDs) that provide fast, low-power, silicon-based mass storage with no moving parts.

e Hardware protection of the system from aberrant software processes (trapping of out of range

addressing and a watch-dog timer on interrupts being disabled).

Real-time clock.

ROM-resident system software.

Graphics LCD display.

A touch sensitive digitising pad that provides a pointing device (only available on some models).

ISDN-8bit standard combo sound system (only available on some models).

The SIBO architecture has primarily been implemented in custom ICs called ASICs. At the time of writing there are ten different SIBO ASICs. Some of these ASICs have been designed for use inside peripherals and these will discussed in detail throughout this document. All SIBO ASICs have been implemented in surface mount packages and are based on a static CMOS technology. Current SIBO products in the MC, HC and Series 3 range are based on the same three principal chips. These are the V30H (an 8086-compatible processor) and two Psion custom chips known as ASIC1 and ASIC2. Later SIBO products including the Series 3a and Workabout have these three devices integrated into a single Psion custom chip known as ASIC9. The V30H is an enhanced 16-bit CMOS version of the 8088 found in the original IBM PC. It is software compatible with the 8088. The V30H is a fully static design which means that all the internal storage elements (i.e. its registers) are made from static rather than dynamic storage components. This in turn means that there is no minimum clock speed required to refresh the storage elements and the system clock can be stopped at any time with no loss of internal state. This technique is used extensively in the SIBO architecture to save power while the processor is idle (i.e. waiting for an event).

The Psion SIBO serial protocol is a proprietary synchronous two wire serial standard by which host Psion handhelds communicate with external devices. These devices will typically be Memory Packs (usually referred to as Solid State Disks or SSDs), RS232 and Centronics printer interfaces, fax modems, bar-code scanners, and so on. The SIBO architecture provides for two basic forms of expansion device, namely the extended internal expansion connection (as with SSDs) and the reduced external expansion connection (the 6-pin S3a serial port or the 11-pin LIF connector). The MC and HC range of computers have two SSD ports and two separate independent single row 25-way extended internal expansion ports. These ports have in addition to a Psion SIBO Channel, direct, parallel I/O from the processor. Direct connection to these machines 7.2 volt battery is included to support high power peripherals such as Printers and Barcode readers. The Series 3 range of computers have two ports for SSDs and a single, reduced, 6-pin expansion port, which provides only a Psion SIBO serial channel and limited power (<25mA). The Psion Workabout has two SSD ports, two internal expansion points, and one external expansion port. The single external expansion port uses an | 1-pin Low Insertion Force (LIF) socket which provides a Psion SIBO channel, 25mA of current and additional lines required for detecting the presence of the Workabout cradle. Each internal expansion port consists of a single row 26-way connector carrying two high speed serial ports.

Revision 1.00 Page 2 of 115 pages

The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

A range of Psion peripherals have been produced for connection to the Psion handhelds outlined above. These peripherals currently incorporate one of two custom integrated circuits (ASIC4 and ASICS) that convert SIBO serial protocol signals to data bus TTL level voltages which enable memory and memory-mapped peripherals to be addressed. ASIC4 is used in SSDs and for memory- mapped peripherals. A typical ASIC4 peripheral for a Psion S3a would consist of an ASIC4 connected to port C of the host machine and a peripheral chip/device mapped into ASIC4's addressing space. ASICS is a general purpose I/O chip with a UART on board that can be run in several different modes. For example ASICS can be used for MCRs (magnetic card readers) or Centronics interfaces thereby simplifying peripheral design. Psion extended internal expansion ports carries an active low interrupt input line to the host controller circuitry. The reduced external expansion ports has an active high interrupt input line. The function of the interrupt can thus be programmed into the host machine's ASIC1 or ASIC9.

The low-level programming interface to a Psion handheld peripheral is encapsulated within an appropriate device driver. Psion device drivers are written in 8086 assembler and follow a prescribed pattern outlined later in this document. The construction of a peripheral and the coding of its complimentary device driver enable the developer to access its functionality through the means of library calls in a C program. Examples of such calls are p_loadldd(), p_open() and p_close(). I/O requests are routed through the device driver's strategy vector which maps to the PLIB p_iow () call. The device driver is built using the Borland Turbo Assembler and resides in a single code segment. The device driver can be stored in either RAM or a ROM on board the peripheral or can be supplied on an SSD (solid state disk).

Revision 1.00 Page 3 of 115 pages

The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

3. HARDWARE OVERVIEW

The Psion SIBO serial protocol

The Psion SIBO serial protocol is a general purpose method of bi-directional serial data transfer. It has been designed for synchronous communication between a host controlling device and a number of slave devices. On a hardware level, the SIBO serial protocol is implemented through Psion ASICs. The controlling device must contain an ASIC2 (or ASIC9) and the slave devices an ASIC4 or ASICS. The various Psion ASICs are described in more detail below.

The synchronous SIBO serial protocol interface consists of 2 wires:

CLK ~ - Aclock output from the controller to the slaves. Nominally 3.84 MHz.

DATA - A bi-directional synchronous data line.

The data is transferred using a series of 12 bit frames including 8 data bits each. This equates to a theoretical maximum data transfer rate of approximately 312 Kbytes/second. Other bits of the frame contain control information. The "system" is generically defined by 2 protocol layers, namely the Physical layer and the Transport layer. These layers are described in detail in the next chapter.

Psion ASICs and what they do

ASIC stands for Application Specific Integrated Circuit and as previously indicated, these devices are widely used within Psion hardware. Summaries of the functionality of each ASIC that is relevant to peripheral development are presented below:

ASIC1: ASIC1 is the main system controller chip for the SIBO architecture. It connects directly to the 8086-based processor (i.e. the V30H) controlling all bus cycles to and from the processor. This configuration effectively forms a micro-controller like device that executes 8086 instruction codes. ASIC 1 is made up of a number of functional blocks including a bus controller, a programmable timer, an eight input interrupt controller, an LCD controller and the memory decoding circuitry.

ASIC2: ASIC2 is the peripheral controller chip for the SIBO architecture. It contains the system clock oscillator and controls switching between the standby and operating states. ASIC2 provides an interface to the power supply, keyboard, buzzer and SSDs. ASIC 2 includes the eight-channel SIBO serial protocol controller and provides interface circuitry to both the reduced external and extended internal peripheral expansion ports.

ASIC4: ASIC4 is a serial protocol slave IC for addressing memory and general memory-mapped peripherals. It is used in SSDs to convert SIBO serial protocol signals into addresses within the memory range of the memory pack. ASIC4 was designed to be a cut-down version of ASICS which was the original SIBO serial protocol slave chip.

ASICS: ASICS is a general purpose I/O chip with a built-in UART that can be set to run in a number of different modes thereby simplifying the task of peripheral design. For example, it is possible to set up ASICS to run as a Centronics parallel port interface, an 8-bit parallel I/O port, a serial bar code controller or a serial RS232 converter.

ASIC9: ASIC9 is a composite chip comprising of a V30H processor, ASIC1, ASIC2 and general I/O and PSU control logic all on one IC. ASIC9 thus integrates all the digital logic required to produce a SIBO architecture computer less the memory onto one chip. ASIC9 has a few additional features such as an extra free-running clock (FRC) and a codec interface for sound.

Revision 1.00 Page 4 of 115 pages

The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

Interrupts

Psion peripherals usually incorporate some circuitry to generate hardware interrupts. Both reduced external expansion ports (such as the LIF connector on the Workabout or the 6-pin serial port connector on the S3a) and extended internal expansion ports (such as the two single row 25-way HC connectors) carry an interrupt line. This is an active high input to the host machine's interrupt controller circuitry which resides on the logical equivalent of ASIC1. The OS intercepts all interrupts and can be requested to call a particular function within a controlling device driver. Eight hardware interrupts are supported by SIBO hardware. IRQO is the highest priority and IRQ7 the lowest. All interrupts are level triggered and must be serviced in the following order:

e Device asserts the appropriate interrupt request line.

e The interrupt controller unit within either ASIC2 or ASIC9 places onto the data bus the vector of the highest priority device with an interrupt pending. This enables the CPU to jump to the correct interrupt service routine code.

e During the interrupt service routine, the software clears the interrupt line by some action specific to the device.

e The interrupt service routine then informs the interrupt controller that the interrupt has been cleared by writing to the non-specific end of interrupt (NSEOD) location.

e If another interrupt is pending then go back to the second step.

With 8086-based processors, it is not possible to have nested interrupts.

The current range of Psion peripherals

There are currently a number of Psion peripherals in use and some of the key ones are outlined below in order to provide the developer with a feel for peripheral design issues:

SSDs: Solid State Disks (or Memory Packs) use a built-in ASIC4 to decode SIBO serial protocol signals into memory addresses within the memory range of the SSD.

Psion 3-link: The 3-link translates the high speed SIBO serial protocol channel on the S3a 6-pin reduced external expansion socket into a serial RS232 format. This enables the host machine to communicate with a PC for example by means of connecting the 3-link unit from the handheld's 6-pin port to the PC's COM1 or COM2 port. The 3-link contains an ASICS which uses its on-board UART to convert SIBO serial protocol signals to RS232 format TTL level voltages.

The HC Printer: The HC Printer translates SIBO serial protocol signals transmitted across the single row 25-way extended internal expansion socket of the host HC into a parallel 8-bit format that is compatible with the universal Centronics printer interface standard. The HC Printer unit contains an ASICS running in Centronics interface mode which acts as the serial protocol slave and requires a small number of support chips.

Psion 3-Fax: The 3-Fax contains an ASIC4 and a memory-mapped modem chip set which permits the host machine to transmit (but not receive) fax messages.

Barcode: The Psion Barcode reader employs an ASICS running in serial mode to read the data received from the barcode decoder chip into a SIBO serial protocol format that can be transmitted to the host ASIC2/ASIC9.

Workabout RS232 Interface: This peripheral connects to the single row 26-way extended internal expansion port of the Workabout. It incorporates an ASICS running in its default mode to translate SIBO serial protocol signals into a TTL level (+/-5v) serial RS232 format using ASIC5's on-board UART. The TTL level RS232 signals are converted into the standard EIA format (+/-12v) before coming out on the conventional RS232 9-pin D-type connector.

Revision 1.00 Page 5 of 115 pages

The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

4. THE PSION SIBO SERIAL PROTOCOL

Introduction

The Psion SIBO serial protocol is a proprietary standard for bi-directional serial data transfer between

a controlling device and a number of slave devices. The synchronous interface consists of 2 wires

CLK and DATA as mentioned earlier:

CLK _~ - Aclock output from the controller to the slaves. Nominally 3.84 Mhz for memory

interfaces or 1.536.Mhz continuous for peripherals.

DATA - A bi-directional synchronous data line.

The data is transferred using a series of 12 bit frames including 8 data bits each. This equates to a

theoretical maximum data transfer rate of approximately 312 Kbytes/second. Other bits of the frame

contain control information. The "system" is generically defined by 2 protocol layers:-

e The Physical layer defining the hardware interface and frame structure.

e The Transport layer defines system control and register transfers between the controller and the slaves.

Using this system, a large number of higher level implementations can be defined. In normal use the

controller will communicate to slaves in a point to point configuration. Multidrop configurations with

a number of slaves attached to one channel of the controller are also supported.

As indicated in the previous chapter, the SIBO serial protocol controller circuitry resides in either an ASIC2 or an ASIC9 depending on the particular Psion hardware platform. The S3a and Workabout employ ASIC9 whereas the HC, MC and S3 use ASIC2.

Hardware Interface

As indicated above, the SIBO serial protocol consists of two lines that switch at 5V CMOS voltage levels:

Clock Line

This line is used to synchronously clock data between the controller and slaves. It is always output from the controller circuitry that resides in ASIC2/ASIC9. The clock should only be active during the transfer of data or when the serial channel is continuous clocking mode (used by ASICS). At all other times it is tri-state pulled low.

Clock Timing Parameters

Parameter Width of Clock High

Width of Clock Low Cycle time of clock Clock Frequency

Data Line

This is a bi-directional line used to transfer data synchronously between the controller and slaves. The direction of the data line is not determined by the physical layer but by the control information in the transport layer. This is described in the next section. When no data transfers are in progress the data line is always set to input on both the controller and slaves. This line is pulled low. Data is changed on the falling edge of clock by the transmit device and latched into the receiving device on the rising edge of the clock.

Revision 1.00 Page 6 of 115 pages

The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

The Physical layer

This section specifies the low level protocol of the SIBO serial protocol. The physical layer protocol consists of a series of 12 bit frames. There are four types of frames:-

Null frames - Transmitted by controller to synchronise slaves.

Control frames - Control information transmitted by controller to slaves.

Data output frames - Data frame transmitted by controller to slaves.

Data input frames - Data frame received by controller from a slave.

Frame structure

All 12 bit frames have the following structure:-

Bit

Name ST

ST Start bit. This bit goes high to indicate the start of a valid frame.

CTL ~~ Control bit. When low indicates this is a control frame. High indicates a data frame. Il Idle bit. Used to turn around direction of data line. Normally Low.

DO-D7 Data bits.

12 Idle bit. Used to turn around direction of data line. Normally low.

Null Frame

This is a special frame transmitted by the controller to ensure all slaves are synchronised. It is generated by transmitting 12 clock pulses with the data line set to input. Since the data line is pulled low this results in 12 zeroes being transmitted.

Control frame

This frame is transmitted from the controller to one or more slaves. The data line is an output from the controller throughout the whole frame. The bits in the frame have the following value in a control frame:

ST Start bit. This bit goes high to indicate the start of a valid frame. CTL Control bit. Low to indicate this is a control frame.

I1 Idle bit Set low.

DO-D7 Data bits. 8 bits of control information.

I2 Idle bit Set low.

Data Output Frame

This frame is transmitted from the controller to one or more slaves. The data line is an output from the controller throughout the whole frame. The bits in the frame have the following value in a data output frame:

ST Start bit. This bit goes high to indicate the start of a valid frame. CTL Control bit. High to indicate this is a data frame.

Il Idle bit Set low.

DO-D7 Data bits. 8 bits of transmitted data.

12 Idle bit Set low.

Data Input Frame

This frame is received by the controller from a slave. The data line is an output from the controller for cycles 1 and 2 and input to the controller for cycles 4 to 11. The bits in the frame have the following value in a data input frame:

ST Start bit. Output from controller. This bit goes high to indicate the start of a valid frame.

CTL Control bit. Output from controller. High to indicate this is a data frame.

Il Idle bit. Used to turn around direction of data line. Both controller and slave

should tri-state the data line during this bit. This bit should be low due to pull

down resistor on data line. The controller changes the data line from output to

Revision 1.00 Page 7 of 115 pages

The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

input at the end of cycle 2. The slave changes the data line from input to output at the start of cycle 4.

DO-D7 Data bits. Output from slave 8 bits of data transmitted by slave. Controller sets data line to input during these bits.

12 Idle bit. Used to turn around direction of data line. Both controller and slave

should tri-state the data line during this bit. Should be low due to pull down

resistor on data line. The slave changes data line from output to input at the end of cycle 11.

Data line direction

The following table summarises the direction of the data line.

CONTROLLER SLAVE Condition CK DATA CK

Outside Frame

Null frame

Control Frame

Data output from controller

Data input to controller:- Cycles 1-2 Cycle 3 Cycles 4-11 Cycle 12

OO000 0004

Key T Tri-state I Input O Output

The Transport layer

This section specifies the transport level protocol that operates above the SIBO serial communication physical layer. The transport layer protocol controls the serial communication between the SIBO Protocol Controller (SPC) and a number of SIBO Protocol Slave (SPS) devices. The following rules apply:-

1) The interface is controlled by the writing of control bytes from the controller to the slaves. Control bytes cannot be written by the slaves.

Unsolicited data cannot be sent from the slave to the controller.

2) The controlling device contains two registers to communicate to the slaves. These are the control register (byte, write only) and the Data register (byte or word, read/write).

Control bytes are transmitted to the slaves by writing to the control register.

The format of the control byte is as follows:-

The control word can have 2 distinct formats depending on the setting of bit 7 the Select (S) bit:- Select = 0 This is the slave select mode. This mode is for selecting, deselecting and resetting slaves. Select = 1 This is the slave control mode. This mode is for communicating with a slave which has been previously selected using the select slave command.

Revision 1.00 Page 8 of 115 pages

The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

Slave select mode

The format of the slave select byte is as follows:-

Key:- R single reset bit. TU 6 bit ID field.

The 6 bit ID field is a property only of the slave. No slave may have an ID of zero, hence there can be 63 different slaves connected to one controller. The reset bit (R) controls whether the slave(s) are selected or reset. If R = 0 slave(s) are reset, R = | slave(s) are selected. Slave select control bytes can be summarised by the following table:-

Description Reset all slaves

Reset specific slave with ID = xx Deselect slave (does not reset slave) Select slave with ID=xx and read slave info (see below).

The Reset function is dependant on the slave. It would normally put the slave into a known passive reset state.

Select Slave with ID=xx (S=0,R=1)

This is a special command that causes a slave with ID=xx to transmit to the controller an 8 bit information field. This field depends entirely on the slave but must be non zero. A reply of 0 indicates that there is no slave of the requested ID present.

Slave control mode

This mode is for communicating with a slave which has been previously selected using the select slave command described above. The format of the control word in slave select mode is as follows:-

R/W Read/write select. 0 = write, 1 = read

B/W Data transfer size. 0 = 1 byte transfer, 1 = word (2 byte transfer). S/M Single/Multi transfer mode. 0 = single, 1 = multibyte.

XXXX = 4 bits of data to slave.

Note the meaning of the 4 bits of data (XX XX) is entirely dependent on the slave.

The settings of R/W,B/W,S/M bits in the control word determine the size, type and direction of subsequent data transfers in the following manner:-

Revision 1.00 Page 9 of 115 pages

The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

R/W B/W _ S/M

0 0 0 write a single byte to slave

0 0 1 write a number of single bytes to slave

0 1 0 write a byte pair to slave (not implemented)

0 1 1 write a number of byte pairs to slave (not implemented)

1 0 0 read a single byte from slave

1 0 1 read a number of single bytes from slave

1 1 0 read a byte pair from slave (not implemented)

1 1 1 read a number of byte pairs from slave (not implemented) Write a single byte

This command readies the currently selected slave to receive a byte of data and sets up the controller so that the next byte (or the LSB of a word) written to its data register will be transmitted to that slave. Anything further written to the controller's data register will have no effect.

Write a number of single bytes

This command readies the currently selected slave to receive a number of sequential bytes of data. The slave will expect to receive data bytes until another control byte is received. The controller is set up so that the next byte (or the LSB of a word) written to its data register will be transmitted to that slave. All subsequent bytes written to the controller's data register will be transmitted to the slave. This will continue until another byte is written to the controller's control register.

Write a byte pair

This command readies the currently selected slave to receive two bytes of data and sets up the controller so that the next word written to its data register will be transmitted to that slave (LSB first). Anything further written to the controller's data register will have no effect.

Write a number of byte pairs

This command readies the currently selected slave to receive a number of sequential byte pairs of data. The slave will expect to receive byte pairs until another control byte is received. The controller is set up so that the next word written to its data register will be transmitted to that slave (LSB first). All subsequent words written to the controller's data register will be transmitted to the slave. This will continue until another byte is written to the controller's control register.

Read a single byte

This command triggers a byte to be transmitted from the selected slave to the controller. This byte can then be read from the LSB of the controller's data register. Further reads of the controller's data register will return the same data but have no effect on the protocol.

Read a number of single bytes

This command triggers a byte to be transmitted from the selected slave to the controller. This byte can then be read from the LSB of the data register. This read will trigger the next byte to be transmitted to the data register of the controller. All subsequent reads of the controller's data register will trigger further bytes to be transmitted to the controller. This will continue until another byte is written to the controller's control register.

Read a byte pair

This command triggers a byte pair to be transmitted from the selected slave to the controller. This word can then be read from the controller's data register. Further reads of the controller's data register will return the same data but have no effect on the protocol.

Read a number of byte pairs

This command triggers a byte pair to be transmitted from the selected slave to the controller. This word can then be read from the controller's data register. This read will trigger the next byte pair to

Revision 1.00 Page 10 of 115 pages

The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

be transmitted to the data register of the controller. All subsequent reads of the controller's data register will trigger further byte pairs to be transmitted to the controller. This will continue until another byte is written to the controller's control register.

Timing The time taken for commands to be processed and data sent is shown below. The time is given in

SIBO pack protocol clock cycles. The length of a clock cycle is nominally 260 nanoseconds for a clock frequency of 3.84 MHz.

Receive and process the control byte 12 cycles Byte transfer to or from slave 12 cycles Byte pair transfer to or from slave 24 cycles

When writing to the controller's data and control registers the following rules apply:-

e After writing to the control register there must be a delay of at least 12 cycles before the data register is accessed or another control word is written.

e Toread a word from the data register after the command to read byte pair is issued there must a delay of at least 12 (for control byte)+24 (for the byte pair transfer)= 36 cycles.

e To perform a multiple byte pair write there must be a delay of at least 12 cycles after the command is written to the control register before the first word can be written to the data register and a delay of at least 24 cycles between subsequent writes to the data register.

States

A slave can be in one of 5 states. Note a control byte can be received and interpreted at any time. 1) Waiting to receive a data byte or control byte

2) Waiting to receive a data byte pair or control byte

3) Waiting to transmit a data byte or control byte

4) Waiting to transmit a data byte pair or control byte

5) Waiting to receive control byte only

Revision 1.00 Page 11 of 115 pages

The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

5. MECHANICAL OVERVIEW

This section will contain information regarding mechanical and plastic moulding for Series 3/3a, Workabout and HC machines that is deemed to be of especial importance to developers who are considering producing peripherals for these particular Psion platforms.

The Psion Series 3/3a range

S3a/Series 3 Reduced External Expansion Port

The Psion Series 3/S3a personal digital assistants have two SSD slots and provide access to external peripheral units through a single reduced internal expansion port, port C, on the left edge of the machine. The reduced external serial interface expansion port from the Series 3/3a forms six wires. The purpose of each is described in the table below. In addition to data, clock and power an active high interrupt line is provided. This allows the peripheral device to generate an interrupt within the host series 3/3a. The level of interrupt that is generated depends on both the machine and the expansion port that is used. Either ASIC4 or ASICS can act as the other end of the Psion Serial Interface. With exception of the interrupt line all used signals should be connected directly to the appropriate pins on ASIC4/5.

ASIC4/5 SDAT MCLK Serial clock ASIC4/5 SCLK

| 6 | SCK/EXON | Not used in this scenario | Donot Connect____|

Signal Definition

MSD and MCLK form a single master SIBO serial protocol channel. This is normally channel 7 on a Series 3 and channel 5 on an S3a. The serial channel clock can be continuously enabled to provide a free running clock for expansion devices. The frequency is fixed at 1.536MHz regardless of the system clock frequency. SDKs/INT and SCK/EXON are both dual function pins. SDKS and SCK form a single slave SIBO serial protocol channel. This can be combined with MSD and MCLK to form a bi-directional high speed data link. SDS/INT can also be used to as an active high interrupt input. The function of SDS/INT can be programmed in ASIC2 or ASIC9. A rising edge on the SCK/EXON input will bring the system out of the standby state into the operating state. VCC is a +5 volt supply that is switched off when the system is in the standby state and is switched on when the system is in the operating or idle state. The maximum current that can be drawn is 25mA. Opening the pack doors on either an S3a or a Workabout will cut power to external peripherals.

Physical Connector

The reduced expansion port is made up of a 6-way two row connector spaced on a 2x3 way 0.1 inch pitch. The diagram below shows the physical connector numbering:

Revision 1.00 Page 12 of 115 pages

The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

Looking into Series 3 / 3a

The male plug is connected to a 0.5m long plastic moulded 3-link cable assembly (part no. 25020013) which is terminated in a six-pin in-line connector which connects to a 6-way 1.5mm pitch transition header (part no. 47000106).

The Psion Workabout

The Workabout Expansion Interfaces

The Psion Workabout provides a rugged and easy-to-use computer system for a wide range of mobile corporate needs. The machine can be readily adapted to support various peripheral units such as barcode scanners and modems attached to the expansion ports. The Workabout has a 26-way extended internal expansion interface and a special 11-pin reduced external expansion interface.

Workabout Extended Internal Expansion Interface

The pin-out of the Workabout 26-way internal Torson connector is outlined below:

Torson 26 way connector pin Workabout Signal name NICD (not used)

THM (not used) VIN (not used)

Revision 1.00 Page 13 of 115 pages

The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

e = Vccl is 3.0V nominal power supply. Current available from Workabout is limited to 100mA.

e =Vcc2 is 5V nominal power supply. Current available from Workabout is limited to 200mA.

e RUN is low when powered down and high when powered up. It is used to power down or reset the peripheral module.

e SCK2 and SCK3 are serial data clocks. The clocks are left running continuously at 1.536MHz when the serial port is in use. They are used to clock the UART in ASICS in the RS232 AT/TTL and AT/Barcode modules respectively.

e SD2 and SD3 are bi-directional serial data lines used in the RS232 AT/TTL and AT/Barcode

modules respectively.

EINT1 and EINT2 are active low signals for interrupt input.

EXON is an active high signal used to turn on the Workabout.

All of the above logic signals are at 3.0V or 3.3V levels, depending upon the logic supply Vcc1.

Lines currently described as unused relate to a yet unspecified codec interface.

Workabout Reduced External Expansion Interface

For the Workabout reduced external expansion interface, a new | 1-pin Low Insertion Force (LIF) connector has been designed for connecting the computer to the Cradle System. The computer mounted male LIF may be weather proofed, the cable mounted female LIF cannot. Currently the LIF connector cover can be moulded with a polarising pin in one of two positions. The facility exists to manufacture the cover with the polarising pin in two more positions, giving four possible variants. If more than four versions are required it is possible to have the cover and the socket bezel moulded in a range of colours to differentiate between variants. The polarising options are presented below:

Pin numbers 1st (1 GROUND 9 2nd (________] SIGNALS 2,3,4,5,8,10 1,6,7,11

The step arrangement of the LIF Connector pins

Cable mounted LIF (Female plug) Computer mounted LIF (Male socket)

Revision 1.00 Page 14 of 115 pages

The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

3S 310

@e0000 08 ODOOOO

Cable mounted LIF (Female plug) Computer mounted LIF (Male socket)

Type A and Type B polarisation of the LIF Connector

Revision 1.00 Page 15 of 115 pages

The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

Pin Definition for LIF - PFS Connector LIF Connector Polarisation Type B

Pin Pin Name Wire Colour Contact Direction Standard Function Cradle usage No Gauge (Cradle's perspective)

1 LCA 710.1 Brown third Input Local’ Computer Active. High when the Used as an enable for the cradle computer is on. (The Workabout can source resident Xmod 5V supply. 100mA from this pin and the HC/HCDOS 5mA to power remote circuitry)

EXON 710.1 Blue second Output EXternal switch ON, active high (+5V). May be asserted by a cradle resident Asserted by a remote” device to switch on Xmod. the computer. Xmod.

se He 1 a eee eet Battery thermistor terminal. Allows remote“ function eae of the battery temperature.

meal 1 Bead ie Output Disconnect Local” ASIC, active high (+5V). Asserted by the Cradle ASIC, (does not apply to Workabout). When this connects the cradle resident Xmod to signal is asserted the serial channel is the serial channel. disconnected from the local? ASIC4/5 in the HC resident Xmod (if present) and instead connected to a remote ASIC4/5 (if present).

FN Te | 7 | vin | 28SwG Power supply to computer (+10V) | 8 | SCLK 710.1 | SerialchannelCLocK.

GND 28 SWG White “fiat Power, [Seval channel Chev —_____ ground and -ve battery Standard function terminal (1 amp)

SDATA 710.1 Serial channel DATA.

11 STATUS 710.1 Pink third Cai STATUS. Connected to a pull-up resistor to Driven low by an open collector driver allow connection to an open-collector/drain when LCA is high and the cradle is driver. Normal usage is: low indicates the powered-up to allow the computer to presence of a remote” device. sense whether or not the cradle is

connected.

LIF Connector Polarisation Type A

Pin Wire Colour Contact Direction Function No eine Gauge (Computer's perspective) ee oe RS2I2 signal a a RS232 signal

77 Output | RS232 signal THERM [7101 [Yellow [ second_[ =] Battery thermistor terminal

[svar [2sswo [Red [tind [- | tvebattery terminal ——SSSSSCSCSCSCSCSCSCSCC~C~* [3 [pe 701 [Grey [second [Input [ RS232signal OSS [9 [exp eswo [white [fist [= | Power, signal ground and ve battery terminal —____——SS—~S

Definitions

Computer HC, HCDOS or Workabout

Cradle resident Xmod Expansion module fitted to the cradle, may or may not be present.

HC resident Xmod Expansion module fitted to the HC, which contains the cradle interface and possibly another peripheral. HC peripheral A peripheral, located in the HC resident Xmod which is connected to the same serial channel as the cradle. Cradle ASIC An ASICS located on the main cradle PCB which remains connected to the serial channel

irrespective of the state of DLA.

1. | The term "local computer" implies the computer local to the LIF connector, i.e. the HC, HCDOS or Workabout, as opposed to a "remote" computer which might be connected via a cradle resident Xmod for example.

2. The term "remote" implies something on the other side of the LIF connector to the computer.

3. | The term "local" implies something on the computer side of the LIF connector including devices on an HC resident Xmod.

Revision 1.00 Page 16 of 115 pages

The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

Exploded view of the Psion Workabout

Below is an exploded view of a complete Psion Workabout showing part numbers for various components and illustrating the positioning of the expansion interfaces.

4 g y o # 4 a § 8 Ss 8 4 gy Fa i f a Of i a 8 a a a « a 2 8G Roo ae 38 a3 3 a @ ¢ me oON Sgt 3 ROS a 3 g ® S +8 Be $3 $s $8 a 8 28 = o j z a 3 a3 F | 8 a 4 9 Boa ey 3 a a 9 3 a g 4g 1 o & & a9 3 4 2 # 8 . p 3 3 zh ae 6 ¢ a 3 i 3 f é i 3 " 3 a8 a 8 2 3 § goa 3 BS g a 8 Poa 3 5 : a 8 a 9 a oF a + & § ff 42 Oo oN bos ng a 3 al a «38 i hoon 2 8 > f a 38 ag eg 2 as & a $3 Gc @ aa 4 a og 3 4 o § 8 g 8 & g 3 a a S$ 0 y 8 3 4 8 d 1 a 3 ages a Be, gy ee! 8 g 3 ae a 3 8 & 4 9 2 3 p t ° ib a oO © 3 Re eS 3 y § 3 4 3 3 ae oe: n oc = «© x » zg a3 xg é a3 28 4 a 3 6 4 4 s 3 ¢ 2 3 os 3 a a 8 § a 4 hoa gs 4 $ 3 ROS * § a & aoa g g 8 i 3 a 3 5 3 3 i rf g Son 8 38 4 og F 2 9 * 3 8 a a 4 j 4:8 8 a5 3 a

Revision 1.00 Page 17 of 115 pages

The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

The Psion HC range

HC Extended Internal Expansion Port

The Psion HC range of computers are intended to provide a rugged and powerful mobile computer system for a wide variety of demanding application requirements. As part of its adaptability, every element of the hardware is configurable from the plug-in SSDs to the expansion ports for peripheral devices such as bar code scanners, modems and magnetic card readers. There are two independent extended internal expansion ports at either end of an HC unit. The top port is termed the "A" port and the bottom one the "B" port. Each expansion port provides direct I/O with the processor, a SIBO serial channel, and connection to the power supply. It allows for higher powered expansion devices to be added by including a direct connection to the main 7.2 volt battery.

Physical Connector

The expansion port is made up of a 25 way single row connector spaced on a 0.1 inch pitch. The 26th position is a polarising key and should be left blank. The correct mating connector on the expansion device is made up from a number of Molex C-Grid series 90148 connectors. Pins | and 2 are ground and should have there own connector placed nearer the board edge to ensure the ground connection is made first when the expansion device is inserted. The required connectors are Molex 90148-1102 for the GND contacts and Molex 90148-1123 for the signal contacts. The diagram below shows the physical position of the connectors.

=$f ene 98148-1182 3

Se : EXPANSION D =e

sad Abe COMPONENT SID

fet

feu) HHDE eorn AEM on

38148-1125

raftats afte + [o}:o loo) en] Heonwnm Zuaorom Scteorn aa ne

raftofea Lsfosfra wn Ox ol Fr!

wi Zo OR

ge

voce (SPACE?

SIBO COMPUTER

Revision 1.00 Page 18 of 115 pages

The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

Signal definition

The following table defines the 25 way expansion connector:-

Pin No. Name _ Sig. type Comments

GND Power Should mate first when device inserted

GND Power Should mate first when device inserted

ADO BCMOS 8 bit multiplexed address and data bus pulled low with 100 K resistors ADI BCMOS

AD2 BCMOS

AD3 BCMOS

AD4 BCMOS

ADS BCMOS

AD6 BCMOS

AD7 BCMOS

ALE OCMOS Address latch enable - high when valid address on ADO-AD7

IOWR OCMOS I/O write strobe - active high, data valid on falling edge of IOWR IORD OCMOS I/O read strobe - high when device can place valid data on ADO-AD7 EES OCMOS External Expansion Select - high during I/O cycles to expansion device SCLX TCMOS 512 KHz SCL signal for SLD bus - usually Hi-Z and pulled low

DNC N/A For future expansion - do not use.

THERM Resistor Connected to thermistor (bottom slot only - top slot DNC)

VBI Battery Connected to the internal NiCd battery (bottom slot only - top slot DNC) Vsup Power Unregulated battery voltage - present all the time

INTR ICMOS Active high interrupt input

_EXON ICMOS Active low input pulled up to Vccl - pull low to switch machine on

SD B CMOS SIBO serial protocol data line - pulled low

SCLK TCMOS SIBO serial protocol clock line - Hi-Z in standby needs a pull down GND Power

Vcc2 Power +5 volt supply, switched off in standby. Max current available = 50 mA

AADNKRWN KH

DNC (Do Not Connect) indicates that the pin should not be connected. The signal types are:-

O CMOS CMOS output to the expansion device.

B CMOS CMOS bi-directional line to the expansion device. T CMOS CMOS tri-state output to the expansion device.

I CMOS CMOS input from the expansion device.

All the CMOS signals including the ADO-AD7 bus are buffered from the main system busses and so present a load of one HC series logic gate.

Direct I/O

Expansion devices can be connected to direct processor I/O space using the following signals; ADO- AD7, ALE, IOWR, IORD, EES and INTR.

ADO-AD7 is the least significant half of the multiplexed address and data bus, this means that up to 128 I/O addresses are available for each expansion device. As only the least significant half of the bus is available and no bus conversion is done only even addresses can be used.

ALE must be used to latch the address from ADO-AD7 for devices that require a stable address. The address is valid on the falling edge of ALE. Note that AO will always be low for valid writes to the expansion device and as such should not be used as an address line, Al should be used as the lowest order address line. AO can be used as an additional enable signal to stop odd I/O accesses disturbing the expansion device.

EES is the External Expansion Select and is high during all I/O accesses to the expansion device, i.e.

for I/O reads and writes to address range 100 to 1FF hex. for expansion port 1, and 200 to 2FF for expansion port 2.

Revision 1.00 Page 19 of 115 pages

The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

IOWR is an active high signal which is high during all I/O write bus cycles. The data on ADO-AD7 is guaranteed to be stable before the rising edge of IOWR and after the falling edge of IOWR. IORD is an active high signal which is high during all I/O read bus cycles. The ADO-AD7 bus is guaranteed to be tri-state before the rising edge of IORD and after the falling edge of IORD. The expansion device must present valid data on the bus when IORD is high, see the timing details below.

INTR is an active high interrupt input to ASIC1. T his can be used as a directly readable bit or as a dedicated interrupt input. It must not be driven high when the system is in the standby state as this input is pulled down and will cause excessive standby current consumption. The diagram below shows the timing of the I/O write and read cycles.

T/0 WRITE CYCLE

ADS-ADT VALID ADDR

VALID WwW

QOD

FES q_Tadstp _ plyTadhidy,

| Tudstp | Tudhld |

IYO READ CYCLE

ADS-ADT VALID ADDR>

} Tadetp fel adhd ,,

| Thztd Trdste Trdhid

Parameter

Address set up time Address hold time Write data set up time Write cycle pulse width

Write data hold time

Time from Hi-Z to data active Read cycle pulse width

Read data set up time

Read data hold time

Note the typical values given are for an HC with a system oscillator of 7.68 MHz.

The SIBO serial channel

A single SIBO serial protocol channel is provided on each expansion port. Expansion port | is connected to serial channel 5, expansion port 2 is connected to serial channel 6. The serial channel clock can be continuously enabled to provide a free running clock for expansion devices. The frequency is fixed at 1.536 MHz regardless of the system clock frequency. This frequency is a multiple of the SLD clock rate and of all normal RS232 baud rates.

High Speed Side Port

Port C on an HC houses an 8-pin in-line connector that allows access to a high speed SIBO serial interface. This interface is currently used only by the HC cradle peripheral. Its pin-out is outlined in the table overleaf:

Revision 1.00 Page 20 of 115 pages

The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

[Pin | Signal | Type | Description,

fo | Sb7_ | InOut__| Bi-directional Serial Data line- Side portC [8 TSEN Input Battery temperature sensor

Power supplies

Two power supplies are available for expansion devices these are Vcc2 and Vsup. Vcc2 is a +5 volt supply that is derived from Vsup. Vcc2 is switched off when the system is in the standby state and is switched on when the operating or idle state is entered. Each expansion device can draw up to 50 mA from Vcc2. If an expansion device requires more than 50 mA or cannot be powered down when the system is in the standby state the Vsup power supply must be used. Vsup is the unregulated supply directly from the main system batteries or from the DC jack input. It will be in the range 5.5 to 12 volts under normal conditions. To use Vsup the expansion device must regulate Vsup to 5 volts with a low drop-out linear regulator. Care must be taken to not be active and driving any signals high when the system is in the standby state as Vsup is always present. This can be achieved either in software or by using Vcc2 as a signal indicating the active state.

Mechanical Information

Mechanical details regarding the numerous build variants and accessories that currently exist for the HC are presented overleaf. The peripheral expansion boards for these build variants are housed in a special plastic casing that can be machined to hold the requisite connectors. In the matrix, ae indicates that the relevant combination of HC and accessory are compatible and an X indicates that the combination is not compatible. Following the build variant table are two diagrams that display exploded views of the HC expansion connector and the HC Expansion Board complete with part numbers and dimensions.

Revision 1.00 Page 21 of 115 pages

The Psion SIBO Hardware Development Kit

Build Variants

With EL Backlighting Without EL Backlighting

Industrial

Non-Industrial

Keypad Variants

53 Key A/N UK 2401-0026 A/N European 2401-0051 A/N Scandinavian 2401-0050 Numeric only UK 2401-0046 DOS Keypad 2401-0147 53 Key A/N USA 2400-0026 HC Expansion Modules

RS232 / Parallel (Printer) 1502-0001 25 way D type (F) + 9 way Mini DIN Certified FCC Class B / Passed VDE Class B

RS232 / TTL

1502-0039 (IP64), 1502-0040 (NON IP64)

9 way D type (F) + 9 way D type (M)

Passed FCC Class B / Passed EN55022 Class B

UK Modem (Asic 8) 1502-0010 RJ 11 connector BABT Approved in UK, BS6301 (Safety)

Barcode Only

HP Wand HBCS-A207 + Plug + EXMOD 1502-0020 Wand Welch Allen + Plug + EXMOD 1502-0021 FCC Class A/ Passed VDE Class B

RS232 / Barcode 1502-0044 9 way D type Quick Loc(F) + 9 way D type (M) Complies with FCC Class A

MCR / Scanner / RS232 1502-0003 Scanner NipDenso + Plug 1502-0022 Scanner DigVision + Plug 1502-0023 Magnetic Card Reader + Plug 1502-0024 Certified FCC Class B / Passed VDE Class B

LIF / RS232 (Under development) 9 way D type (M) + 9 way LIF- PFS (M)

LIF / TTL (Under development) 9 way D type (F) + 9 way LIF- PFS (M)

LIF / BARCODE 1502-0043 9 way D type Quick Loc(F) + 9 way LIF- PFS (M)

Vehicle / TTL 9 way D type (F) + 9 way LIF- RS232 (M)

16550 RS232 / TTL (Under development) 9 way D type (F) + 9 way D type (M) Complies with FCC Class A

Printer (High Res.) 1502-0037 Laser Scanner 1503-0012

Fast Charger Variants

Fast Charger with Holster (Due Jan 95) Fast Charger without Holster (Due Jan 95)

Additional Accessories Nicad Battery Pack 500 mA 1503-0005

Revision 1.00

Psion PLC (c) May 1995

CHARGER

a a a Ee i ie IE a a ee ee Re ca Da ca

ans he ae Ss eee FS a a a a

Page 22 of 115 pages

Psion PLC (c) May 1995

The Psion SIBO Hardware Development Kit

Corporate Hand Held (CHH)

Expansion Module Exploded Assembly Drawing

(yovig) Sso0-zoz9

(USENNN LYVd YSLINO OSTY) (A3N9) £000-20z9

YANVIG NOISNVdX4d 138V1

(440 2) 2000-z0¢g WSO IZOd WWOXZZ% MINIS

(OV1E) 9107-2018

(AJN9) 9101-2018 ONITINOW Y3LNO NOISNVdxX3 OLS HHO

(wov1d) $10Z-Z018 (AIUD) SLOL-ZOL8 ONIGINOW YSNNI NOISNYdX3 HHO |

6000-0072 ANVIG dd

SNOISNSNIG YSLLNS ANVIG NOISNVdX3 138V1

Page 23 of 115 pages

Revision 1.00

Psion PLC (c) May 1995

t

The Psion SIBO Hardware Development

QrOr o22 ILD :xW4 008! 802 120 “7131 1G) HIM

NOONOT N/OIl

AS 18NOQYVH 61-21 Jd NOd

MSV LENOd Ni dl JNWOS ION OG

(SOs 2) ONDOEL =O w300 34 OL G3U0Y vey

26,

94 01 GMQy SFI NOILWOOT

26/1/91

Sa @ SINSNOGNOD 40 wa) 38 OL G200V vw

26/0178

‘Gadd NOWOWISIS AHOIBH LN3NOEWOD W207

06 /c0/zal

108 X3T0K a300¥ $89 8ou93~N09

oss 9792

SSI Sas

SONVHO,

SmAOVd NOISNVdx4

SH T1¥ A044 GssyINGS

NOILYWAOSANI 4H

L SMOHS SONIMVAC Sit

LH513H LN3SNOdWOD X¥W ONIMOHS 311 408d

216

cay) Y_NOISN3WIC

C30N31LX3

CAVONVLS

JdWwOS aNv

qa.0N3d vaav

A11V901 NO3IaLS34

COMPONENT HEIGHT RESTRICTION

(SEE PLAN VIEW)

(SOd 2) ONIMDVYL ANY WOS4 3384 38 O1 voav

CAVA 92 WiOL) SYOLO3NNO9

LTO

SOd 2) SIN3NOdWOD ANY WOSs 3384 34 OL vaav

: @szaze @ S3143S 8y106 X370N

a2

4.5 BOTH SIDES

1 | 31.75 CRS l 31.75 CRS

Page 24 of 115 pages

Revision 1.00

The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

6. ASIC 4

What is ASIC 4?

ASIC4 is custom integrated circuit designed for use in Memory Packs (called SSDs) and peripheral devices. Its primary purpose is to convert the PSION Serial protocol into the signals required to address memory and memory-mapped peripherals. A typical Series 3/3a ASIC4 peripheral will consist of an ASIC4 connected to port C of the host machine and a peripheral chip/device mapped into ASIC4's addressing space. An example could be an ASIC4 connected to a simple 1k memory device:

Chip select

To write a value, <v>, to address <addr>, the appropriate control codes must be sent along the port C Psion Serial link to assert <addr> on ASIC4's address outputs and <v> on ASIC4's data outputs.

ASIC4 Addressing and Modes

ASIC4 has an 8 bit data bus and a 28 bit address bus. Also provided are eight chip select lines that form selectable addressing blocks each of a size defined by software. The default is 32Kbyte/block. The filing system will set this to the appropriate size while accessing memory in the upper portion of the address space.

ASIC4 has two basic modes of operation, namely ASIC5 Compatibility (or SSD) mode and ASIC4 Extended mode. To select the mode, ASIC4 must be selected with an appropriate ID. This is achieved by writing a SIBO serial protocol slave control frame, as detailed in chapter four, to the ASIC prior to sending any read or write requests. After sending this frame, the so-called Info Byte is read off the data bus. Details concerning the meaning of the various Info Byte bits are provided in the following section. In the case of SSD mode, the ID is 2 and for ASIC4 Extended mode, the ID is 6.

Putting ASIC4 into SSD mode makes the chip compatible with all current versions of existing SSD software in production by Psion including all HC, series 3/3a and MC software. In this mode, ASIC4 mimics an ASICS in pack mode (see next chapter). This is because ASIC4 was originally designed to be a cut-down version of ASICS and so from the outset it was necessary to make previously existing ASICS software run on the new chip. The maximum address space in SSD mode is 21 address bits and 4 chip selects (which comes to 4 x 2Mb). In ASIC4 Extended mode, ASIC4 is capable of addressing up to 28 address bits (256Mb). In this mode, in addition to the Info Byte, a further 4 bits of information can be elicited from the state of the address lines A27-A24 during reset. Of these bits, the state of A27 (bit M) determines whether ASIC4 is going to be used as a standard SSD (M=0) or in a mixed mode (M=1) comprising of memory devices and peripherals. It is only the latter case which is of interest to the potential developer since this is the mode intended specifically for peripheral type expansion. In mixed mode ASIC4's address space is split into two equal halves. The lower half of the addressing range is set aside for memory-mapped peripherals and can be used for any purpose. The upper portion of the address space is reserved for pure memory. The Series 3/3a, Workabout and

Revision 1.00 Page 25 of 115 pages

The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

HC filing system is able to use this memory (which does not have to be present) as an additional storage medium. Typically it will be a ROM containing the software that controls the peripheral. On reset, configuration data is supplied to ASIC4 on its data bus lines which the filing system can read in order to determine what form of and how much memory it has available in this upper region.

In mixed mode chip selects are split into four selectable peripheral blocks and four selectable memory blocks. CSO-CS3 are for peripheral access. CS4-CS7 select memory devices one to four. This set-up is illustrated below:

Peripherals S1 $2 $3 Total Addressing S4 Range Memory (256Mb) SS S6 S7

Reset and configuration

As indicated earlier, in mixed mode, following a reset or power up ASIC4 will read the form in which to configure itself from the data on data lines DO-D7 (the Info Byte) and address lines A24, A25, A26, A27 (most significant nibble of the Extended Info Byte). The table below shows the meaning of each of these lines during reset.

| A27 | A26 | A25 | A24 | D7 | Do | Ds | D4 | D3 | D2 | Di | DO |

Don't care, some 000 RAM 00 1 device No memory codes are reserved. | 001 Typel Flash | 01 2 32Kbyte 000 No peripheral | 010 Type2 Flash | 10 3 64Kbyte

001 T3Link 110 ROM 114 128Kbyte 010 3Fax 256Kbyte Contact Psion for 512Kbyte an official code. 1Mbyte

Pull up, pull down resisters would usually be used to place these lines in the desired state on reset. High value resisters of typically 100k would be used to allow ASIC4 and bus devices to drive these lines to other levels during normal operation.

ASIC4 should be powered from its host Series 3/3a/HC. High current peripheral chips or volatile memories should have their own supply. Whenever the Series 3/3a/HC is powered down, has its batteries removed, or has it's pack doors open, any attached ASIC4 will be powered down and reset upon resumption of power. Taking the 3Fax as an example with one Read Only Memory device of 512k the required configuration is:

Revision 1.00 Page 26 of 115 pages

The Psion SIBO Hardware Development Kit

ASIC4 Pin-out

Pin No Pin Name 50 DO 49 D1 48 D2 47 D3 46 D4 45 D5 44 D6 43 D7

13 AO 12 Al

11 A2

8 A3

7 A4

6 AS

5 A6

4 AT

3 A8

2 AQ

1 Al0 64 All 63 Al2 62 Al3 61 Al4 60 Al5 29 Al6 28 Al7 27 Al8 25 Al9 24 A20 23 A21 22 A22 21 A23 20 A24 19 A25 18 A26 17 A27 37 CSO 36 CS1 35 CS2 34 CS3 33 CS4 32 CS5 31 CS6 30 CS7 16 OE 14 WR 15 VPS 39 POR 40 SCLK 38 SDAT 59 SDIR 51 LBO 56 MCSD 52 INO 53 INI 54 IN2 55 X2D2 57 ATST 10 VDD 42 VDD 9 GND 26 GND 41 GND 58 GND

Revision 1.00

Direction VO vO

fe)

~*=“O0O000000000

fo)

PWR PWR PWR PWR PWR PWR

Pin Description

Databus

Databus

Databus

Databus

Databus

Databus

Databus

Databus

Address bus - register ATO Address bus - register ATO Address bus - register ATO Address bus - register ATO Address bus - register ATO Address bus - register ATO Address bus - register ATO Address bus - register ATO Address bus - register AT 1 Address bus - register AT 1 Address bus - register AT 1 Address bus - register AT 1 Address bus - register AT 1 Address bus - register AT 1 Address bus - register AT 1 Address bus - register AT 1 Address bus - register AT2 Address bus - register AT2 Address bus - register AT2 Address bus - register AT2 Address bus - register AT2 Address bus - register AT2 Address bus - register AT2

Address bus - register AT2/Oscillator Output in PSPRAM Mode

Address bus - register AT3 Inputs to set device size on reset Address bus - register AT3 Inputs to set device size on reset Address bus - register AT3 Inputs to set device size on reset Address bus - register AT3 Inputs to set device size on reset Device chip selects

Device chip selects

Device chip selects

Device chip selects

Device chip selects

Device chip selects

Device chip selects

Device chip selects

Output Enable/Refresh in PSRAM Mode

Write pulse

VPP control

Reset input

Serial clock input

Serial Data input

Protocol Direction indication Bit

Low Battery detect driver output (Open drain)

PSRAM Mode Select

General Purpose inputs

General Purpose inputs

General Purpose inputs/Refresh Disable in PSRAM Mode Oscillator Input for PSRAM Mode

Test input (pull high to put device into address test mode) Power inputs

Power inputs

Ground

Ground

Ground

Ground

Psion PLC (c) May 1995

Page 27 of 115 pages

The Psion SIBO Hardware Development Kit

A11 A12 A13 A14 A15 SDIR GND ATST PS OSCIN IN2. IN1 INO LBO DO D1

- LU Li Lt Ly ae L Ls LI Li

62 61 60 57 56 54 53 52 51

64

A10 48 D2 AQ 47 D3 A8 46 D4 A7 45 D5 A6 44 D6 AS 43 D7 A4 42 VDD AS ASIC4 41} —J GNo

GND 40 SCLK VDD 39 POR A2 38 SDAT Al 37 cso AO 36 cs1 WR 35 cs2 VPS 34 CS3 OE 33 cs4

17° 18 «#19 20 21 22 23 24 25 26 27 28 29 30 31° 32

Rigizipininigiolgipinipimdeig

A27 A26 A25 A24 A23 A22 A21 A20 A19 GND A18 A17 A16 CS7 CS6 CS5 OSCOUT

Diagram of ASIC4 Pin-out (NEC)

Revision 1.00

Psion PLC (c) May 1995

Page 28 of 115 pages

The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

7. ASIC 5

What is ASIC 5?

ASICS is custom integrated circuit designed for use in Memory Packs (called SSDs) and peripheral devices. ASICS provides three primary functions. A built in UART provides for serial communication at baud rates of up to 48000 baud. General purpose I/O pins provide for a wide range of control and communication applications. Finally ASIC5 provides address and data lines for access to memory devices and memory mapped peripherals. A typical ASICS peripheral such as the 3Link consists of an ASICS connected to port C of a series 3/3a, a ROM memory device mapped into ASICS's addressing space and line drivers to convert the UART signals from ASICS into standard RS232 levels.

Chip select

ASIC5 rea Memory

RS232 Line Drivers

Psion Serial link

ASIC5 Modes

ASICS can operate in two modes. In pack mode ASICS generates all the address, data, and control signals necessary to access memory devices. No peripheral functions are available in this mode. In peripheral mode ASICS has only limited memory address capabilities as some or all address and control lines are reused for I/O purposes. ASICS is placed into peripheral mode by setting the peripheral bit in ASIC5's PBMODE register.

ASIC5 as a UART

ASICS contains a full function UART which supports baud rates of up to 48000 bits per second. In order to use ASIC5 as a UART, ASICS5 must be placed into peripheral mode. In this mode the input signals PAO, PAI, PA2, PA3 become the UART inputs RX, CTS, DSR, and DCD respectively. The output signals PDO, PD1, PD2 become the UART signals TX, RTS, and DTR. Serial data is transmitted from the TX line. Incoming serial data is received by the RX line. RTS and DTR can be used for handshaking or as general purpose outputs and need to be set high or low explicitly by software. CTS, DSR, and DCD can be used for handshaking or as general purpose inputs.

The Psion SIBO serial link which connects ASIC5 to a host computer is a two wire interface consisting of a data and a clock line. ASICS generates it's baud rate clocks from this clock line. Under normal operation, clock pulses along a Psion SIBO serial link only accompany data frames. To be able to generate baud rate clocks ASICS requires a steady clock from the Hosts Psion port. To facilitate this, Psion serial links can be put into a mode called continuous clocking where clock pulses are generated regardless of whether there is any actual data to be transferred. Continuous clocking

Revision 1.00 Page 29 of 115 pages

The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

increases power consumption and Psion serial links should not be left in this mode unnecessarily. The UART portion of ASICS is capable of generating interrupts when characters are received, when the transmitter is awaiting a character to send and when there is a change of state on the handshaking lines. ASICS has only one, active high, interrupt line. This line is shared between these interrupt sources. When an interrupt is generated it is the responsibility of software to determine the cause of the interrupt.

A character to be transmitted should be written to the Transmitter Holding Register where ASICS will convert it to serial form for transmission. The register will be emptied once the character has been transmitted. ASIC5 contains no internal buffering. The Transmitter Holding Register must be empty before writing a character to it. The state of the Transmitter Holding Register is reflected in the Transmitter Empty bit in the UART status register. Enabling the Transmitting Holding Register interrupt will cause ASICS to generate an interrupt every time that the Transmitting Holding Register becomes empty. Reading the UART Status Register will clear the interrupt. Received characters are copied into the Receive Character Register. If the Receive Character Interrupt is enabled, ASICS generates an interrupt on each character received. If the character is received in error due either parity, framing or overrun errors, appropriate bits in the UART Status Register are set to reflect this.

ASIC5 for parallel I/O

Lines PAO-PA7 form a general purpose, non latched, 8 bit input/output port. All access to this port take a total of twelve clock cycles. The clock is generated from the Psion Serial Link. Actual memory access cycles only last for one clock cycle. Twelve cycles are required because data being sent or received needs to be converted to or from the Psion serial format. Because of the conversion read accesses occur on the third cycle, write cycles on the twelfth. This is usually of no real consequence to the peripheral designer

In peripheral mode CSO will be taken low for one clock period each time Port A is accessed. Data outputted from this port will remain valid for only the period that CSO is low. In pack mode Port A forms the data bus in memory mapped systems. A read from or write to Port A in this mode will result in one of the lines CSO-CS3, being taken low for one clock period. The line which will be taken low will depend on the address being generated for the access. During read cycles OE line will be taken low and remain so for 10 cycles. Data present on PAO-PA7 must remain stable for the last nine cycles. During write cycles the WR_B line will be taken low for the second half of the cycle over which one of CSO-CS3 is low. If port B is set to counter mode, accessing port A will result in the counter being incremented upon completion of the access.

ASICS can be programmed to generate an interrupt whenever the state of line PA4 changes. Reading port A will clear this interrupt. One use of PA4 is as the BUSY line in a Centronics port implementation.

The Lines PBO-PB7 can be programmed to operate in four different modes. Two of these modes are for testing purposes and will not be discussed further. In latched mode, data written to the Port B resister is latched onto the Lines PBO-PB7 and will remain there until a following write to Port B or a reset condition occurs. In counter mode, the binary value on lines PBO-PB7 is incremented following any access to port A. With ASICS in pack mode lines PBO-PB7 form the address lines AO-A7. Placing port B into counter mode allows 256 consecutive memory locations to be read without need to set-up the address of each access.

Lines PDO-PD7 are general purpose outputs. In pack mode these form the address lines A8-A15. In peripheral mode lines PDO, PD1, PD2 become UART outputs.

Lines PCO-PC4 in pack mode form the address lines A16-A20. In peripheral mode lines PC4 and PC7 become inverted inputs and can be used as edge triggered interrupt lines. PC5 becomes the interrupt output line. PC6 becomes a general purpose latched output. PCO-PC3 become a dual synchronous serial port for use in magnetic card systems.

Revision 1.00 Page 30 of 115 pages

The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

ASIC5 for Barcodes

Psion barcode peripherals use the UART functionality of ASICS to receive data from a dedicated barcode scanner IC.

ASIC5 for Card readers

Magnetic card readers generate clocked serial data. ASIC5 contains two synchronous serial ports for connection to card readers or other peripherals which generate clocked serial data.

Reset and configuration

Following a reset or power up ASIC5 will read the form in which to configure itself from the data on data lines PAO-PA7. Line PC6 is used to select whether ASICS is to operate in pack or peripheral mode. The table below shows the meaning of each of these lines during reset. In peripheral mode lines PAO-PA7 should be set to give an indication of the type peripheral the ASICS is forming. combinations of types can be used.

000 RAM 00 1 device No memory

001 Typel Flash | 01 2 32Kbyte

010 Type2 Flash | 10 3 64Kbyte

110 ROM 114 128Kbyte

1 1 1 Write protect 256Kbyte 512Kbyte 1Mbyte

Peripheral Mode Type

RS232 port Centronics (Parallel) port

Hx KK KK XX xo KKM KK XX

0 0 0 0 0 0 0 0

Pull up, pull down resisters would usually be used to place these lines in the desired state on reset. High value resisters of typically 100k would be used to allow ASICS and bus devices to drive these lines to other levels during normal operation.

ASICS should be powered from its host Series 3/3a, Workabout or HC. High current peripheral chips or volatile memories should have their own supply. Whenever the Series 3/3a/HC is powered down, has its batteries removed or has its pack doors open, any attached ASICS will be powered down and will be reset upon resumption of power.

Revision 1.00 Page 31 of 115 pages

The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

ASIC5 Pin-out

A10 Ali A1l2 Ai3 NC A14 A15 DO D1 D2

DONO o net

ASIC5

14 15 16 17 18 19 20 21

MAMAMAAMMo

WR VPS OE A20 A19 NC A18 A17 A116 CS3 CS2

ASIC 5 current pin-out (TI version CF30179)

Revision 1.00 Page 32 of 115 pages

The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

8. EXAMPLE PERIPHERALS

The ASIC4 Example Interface Board

The ASIC4 Example Interface Board detailed in this chapter is intended to provide the developer with a simple example of a Psion ASIC4 peripheral. To this end, the actual practical usefulness of the hardware is of secondary importance. In fact, the board essentially consists of eight LEDs connected via some latches to an ASIC4. Using a device driver, the host machine is able to control the status of the LEDs. Specifically, the board translates SIBO serial protocol signals into a parallel 8-way data bus format that can be used to set the various 74HC series latches and gates. It is intended that the board can be readily adapted to run on all currently available Psion machines. The only physical change that need be made concerns connection to the host machine's external expansion interface.

In the following circuit, an eight-bit tri-state data buffer, U3, and an eight-bit output data latch, US, are commoned together to the eight LEDs thereby enabling their status to be sensed and set. In addition, a facility for generating hardware interrupts is provided by means of a suitably connected switch, S1, and a third eight-way buffer, U4. U4 is the interrupt switch status buffer. It holds the values of the two input switches S2 and S3 which are read as part of the interrupt service routine. Depending on the value of the switch positions, a different response can be output to the LEDs from the set buffer, US. One of the D-type flip-flops in U6 is used to latch hardware interrupt signals into the INT line (pin 5) of the reduced external expansion interface connector. On completion of the interrupt routine code, it is necessary to reset this flip-flop and hence the interrupt hardware by means of a write to address Al. Address decoding is provided by two 2-to-4 decoders on chip U1 paralleled to address lines AO and Al. A circuit diagram of the ASIC4 Example Interface Board is presented overleaf for the case of a host S3a.

Note that it is possible to construct this circuit with or without the compiled driver code in an on- board ROM. The developer merely has to set the resistors on the three data bus lines DO-D2 such that the corresponding info byte conveys the appropriate information. The meaning of the various bits in an ASIC4 info byte was discussed earlier in chapter 6. If a ROM is to be used, then the info byte read off DO-D7 on reset should include bits 001 on lines D2-D0. This requires the R1/R2 optional resistor to be connected to Vcc. If a ROM is not used, as was the case with the constructed test circuit, the data bus lines D2-D0 should be set to 000. This is done by choosing the resistors connected to ground from the three R1/R2, R3/R4 and R5/R6 pairs.

Revision 1.00 Page 33 of 115 pages

Psion PLC (c) May 1995

The Psion SIBO Hardware Development Kit

VOD voc voc voc voc 3 cs ca cio _|+ caa For 128K Bute ROM fit option resistors Ri, R4, RG, RE and Rio eibe idon toon ioon Our evs For no ROM fit option resistors RZ, R4, RE bo 2 ue ve ve as VOD SNC GND GND GND 1 3 Xf RE-/R4 vor GND res Di 2g 100K ag voo | 338 bo = ae base es Do Di 14 Bd 1 AS Bi DE Be be (45 De veo DS ce be Cie mE v Biel Da 18 ba SNC oS ba Te DS az BS R22 [ery AS be 20 [T= 3 100K Br aS BS [ei isk RE RE aio fa 100K ort ze | 22 bz z Al2 ails oe [24 7 ate 1 aaa oe awe hae Aiz L ae GND eto nigga | ao vor voc ZEK—ine ROM DS R16 100K Ss Is RT-RE RS/RL0 vos z z 7 FaHcT4a ja oR oR R26 Rea 100K 1 1 DF R20. 100K LooR GND GND Ree SND aoe t R27 ba voc LED GND CONNL sp7 bo * 0 sck7 b-# = Bo 18/ivi = 1ai +329 = Di is a_i LED ND sDSs/INT iv2 0 1Az SCKS/“EXON a Wie D2 14 is. 1AS & P2 z z Ds iz = Ps Wor * a vo ava iaa 4 z bas ii_F4 She , a. be revi 281 Ge re LED GND YE 2Yz ZAz CON COMMS CONN be oer te be S| S02 282 (re Pe bre) S)5: Soy bere FPS4HC1sg GND te het LED GND vor 28 brs DL uza 1 OE 4 ae FaHceas FaHCETS z 3 ORD LED ND 2 cso 2 FaHca4d A t ua WF Baves clr Se T4Hese DO 18 Tyg LAL GND 1006F El tel ge: {ee LED GND 1B a De 14 ive 9 1az Mee Nf 14) 4 vo BS tetiva iad D2 GND U2B is ba 3 B vi Zvi ZAL 4 WR 4 oS + LED GND Y2 2vz BAZ = 6 Lor 15 bss Gc YS 2yYe 2As =P = Dre 3/oy4q Baa FaHCLss yo OBAYSS FaHese ee 470 LED GND GND Vos a Si voc ¥ v vos J" GND SND DATA OUTPUT vor FaHCe44 DOS la Us6Al Lk Interrupt Sw a: = Ne Saal = a B Db 2 CC? 1993 (PSIOS PLS. aa ADDRESS R-M FUNC 3 Interrupt In + Bava fal RYH Read & write to latch SLK Eiki Sp ee) omnes GND rs Md Clear Interrupt els; = R25 1 R Read status 100K Poe REY : oO status Bit Func F4HCr4 Title a Ineut a L Tneut 1 > ASICS Example IF 2-5 Not Used GND GND Size Pocument Number REV 6 Interrupt Line B 7 lo.s ? Interrupt Latch : Date: Aerial 19, 1995|[Sheet i_of Z

Page 34 of 115 pages

1.00

1S10n

Rev

The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

The Psion 3-Link

The Psion 3-Link is an ASIC5-based peripheral that enables the user to transform SIBO serial protocol signals into RS232 format data so that a host Psion machine can communicate with a PC or printer. The diagram below shows the schematic of a TTL level RS232 based expansion device. The interface is based around ASICS and allows the standard RS232 device driver contained in EPOC to be used.

Transistor Q1 provides a switched power rail for any other expansion device. This rail will automatically be switched off when the RS232 port is closed. D1 is required to isolate the supply so that the external device does not back power the SIBO computer when it enters the standby state. If the additional device does not require a supply or only uses a few microamps then Q1 and D1 can be omitted. Vcc and the supply for the expansion device can be directly connected to Vcc2.

If CMOS level RS232 signals are required then IC1 can be replaced with a 74HC244 device. If inverted sense RS232 signals are required, IC1 can be replaced with a 74HC241 device.

The diagram overleaf shows the circuitry for an ASICS-based 3-link with ROM.

Revision 1.00 Page 35 of 115 pages

Psion PLC (c) May 1995

The Psion SIBO Hardware Development Kit

vec Rig Icz vec 100K 64/128K PROM SITE E B ag 12Tag wy po Laz ba ta ¥ 14 Di AL D1 To é TS Be Az Dz g id Da as DS 3 tg ba Aa ba id 15 DS aS DS 20 DE AS De }s¢ = ay DF ae voc voc ag Alo vec AlL - A1lz ne |S? ars ver 4 i Ais Pst [22 +08 ce cz $3 rea Our /25v idon io0n Ale. + N B * T le t GND GND ND Fs ey eee 2g Re 100K TRL + BCH 1 cs cz + 1ur/50¥ LuF/so¥ GND vee mS 1 | s aL rs 82 (ita 1 ies veo 22 [aa i wees 23 i 19° + iOurv2sy D1 Fi 14 + ¢ 13 " 24s ex i ca | 1 4 aa c = vor 15 | coy yo LAZ ayes 2 t 16 7 SKT1 CASE za 2- Fi Teu uF 7254 BAYS? I FaHorS 7d TitN taout 2 GND SKTL 36 e _DTR PBO PAD TBIN TZOUT RLSD/bco| ba PBL © pai }32 294 7 SIN TzouT 2 rs RX 4 tad Sa ei ze _Tx x * PBZ paz [3 T4IN T40UT Tx 2 PES paz = 3 Pare DIR PB4 paa [22 £4 R1OuIT R1IN p32 _RX__§_+ t GND a ee PBS pas fed eno se] RZOUT R2IN Pst—Bek . DSR PES Pas pse 25) REOUT RSIN bee—GeR 4 RTS PE? PA? R4ouT RaIN * cts DS, ig Te RI * a WEE RS0UT . RSIN * RI PDO poco i at S| = a PDL pci H2 24 eR ql sp }25 SIBO RS2S2 CONNECTOR PDE pez He ibe Ria L c BAYSS co: pea fas REG Too 100K a mMaxzan GND 12 ciolesilcizicizicis4 PDS pes SMB PDS roe 3S PD? pe? L414 L GND in Jin Jin Jain Jain | 1008 R4 25 /ep zen b24 GND vovVoov¥ vo 1O5R at 27 €39 Pox GND GND GND GND GND ' CLK eSi 26 2 FOR cs2 i7q Fo s T 3g N53 PIL cs NG BD ¢np PL2 fh 100pF iz veo asics [8 4 GND GND ND R? RL 100R 100K Sue o——___| cL SH SPDT vee 100n CONNI cer GND SRT ee RG RS SDS/INT BS Copuriaht CC) Psion PLO 1991 ScKS/ExON PS Vee bs File name! CONHH DRAFT RS232.5CH yee Bg ioorR is a 10k Braun: MG CON COMMS CONN R20 B2xe4—Cay7 PCB Rey 1.4 100K Title ¥ 2|a GND Rev 1.2 Move SD (pin 25 IC2> from pin 23 to 21 of Ici : EONSUMER Bases ExCeL on Rev 1.3 Alter Ri? from 100K to 10K Size Pocument Number REV Rev 114 Added C1io—c14 = Rev 1.5 Moved C3 to CLK input GND GND is 6500.0008 cata Date: June i0, i953 Sheet i oF L

Page 36 of 115 pages

1.00

1S10n

Rev

The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

9. DEVICE DRIVER OVERVIEW

Introduction

Once a piece of peripheral hardware has been designed the appropriate software must be written to control it. All hardware on Series 3/3a, Workabout and HC machines is controlled by logical and physical device drivers. These act as the logical low-level software interface between a piece of hardware and an application that uses it. The remainder of this document is concerned with the methods by which a device driver is able to communicate with and thereby control an ASIC4 or ASICS-based peripheral.

APPLICA TION SOFTW ARE

Psion C PLIB call interface LOGICAL DEVICE DRIVER

PHYSICAL DEVICE DRIVER

PHYSICAL HARDW ARE

This chapter is intended to guide the programmer through the central issues involved in writing device drivers for peripherals that attach to the family of Psion host machines based around the proprietary SIxteen-Bit Organiser (SIBO) architecture. The purpose of a device driver is to abstract away the hardware details required to conduct communication between a peripheral and a software application that uses that peripheral. The device driver therefore performs the logical processing required to translate low level hardware instructions into high level application services. Psion device drivers are written in 8086 assembler and following convention are divided into a logical layer residing over a physical layer. A physical device driver (PDD) contains the code required for talking directly with the hardware device and provides a set of low level hardware specific services. A logical device driver (LDD) performs the logical processing that transforms these low level services into the high level services used by an application. This two-layer nature of device drivers at Psion can be illustrated by the following example. An application using the serial driver decides that it requires RTS/CTS handshaking. It calls an LDD which decides whether or not a line should be driven. If the answer is yes, the LDD calls the appropriate PDD and asks for a particular line to be driven to a specific state. The PDD duly carries out the requested service. Psion SIBO machines often use the same LDD with a PDD written specifically for each version of the hardware device. In such a situation, splitting the device driver is highly desirable. In the example given above, however, the LDD could have talked directly with the hardware negating the requirement for a separate PDD. Similarly, most external peripherals would normally use an LDD.

An LDD must provide a minimum of eight functions for use by the operating system. The functions are passed to the OS via a table of function offsets (referred to as the vector function table). These functions are mandatory. Similarly, a PDD must provide two functions for use by the operating system and may provide more if required. An LDD will usually provide further services/functions for use by an application. The form these take is dependent on the LDD requirements and the functions supplied by the associated PDD(s).

Revision 1.00 Page 37 of 115 pages

The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

Psion SIBO machines are supplied with a set of resident device drivers built into the ROM each of which can be replaced with an installable device driver having the same name. Installable device drivers can also be added to increase the number of available device drivers. Installing a device driver is carried out dynamically without resetting the machine (this is not the case with many operating systems).

Device Names and Channels

The name of a device driver is the mechanism by which an application can obtain a channel to that device driver. A logical device driver name always has three characters followed by a colon. For example, "TTy:" is the serial LDD. This name is required to uniquely identify the LDD to the EPOC OS when attempting to open a channel on it. A physical device driver name always has the three characters of its owning LDD followed by a period, a further three characters and a colon. For example "TTy.UAR" is the ASICS UART driver and "TTy.srRx" is the 16450/16550 driver. The first three characters of a PDD name are the name of the LDD to which the PDD belongs. The second set of three characters uniquely identify the PDD. Thus in the above examples, both PDDs belong to the "tty:" LDD.

A channel can be opened on an LDD by calling the PLIB library function p_open. EPOC uses the driver name passed through an application p_open call to invoke the IoOpen operating system service. This service in turn calls the associated driver ‘open vector’ which can decide whether or not to open a channel on the driver. The assembled ASIC4 Example Interface Board logical device driver, A4EXIF.LDD, for example, has the three-character device name "LED" so a channel with its handle in pcb may be obtained on it by means of the following call:

p_open(&pcb, "LED:", -1)

In this call, the third argument refers to the open mode and a value of -1 indicates that the mode parameter is to be ignored. To obtain a channel on a PDD, an application should call the DevopenPpp OS service. Typically, only LDDs open PDDs though the p_open library function can be used to open a PDD indirectly as illustrated in the following example:

p_open(&pcb, “"TTY.UAR:", -1)

For a device driver configuration consisting of an LDD and a PDD, the application will usually open a channel to the LDD only: the LDD as part of its initialisation would open a channel to the required PDD. If an LDD requires a PDD and none is specified, it is up to the LDD to either fail the open request or hunt for a loaded PDD that it can use. An LDD uses the DevFind OS service to search for a PDD as for instance in the case of the "TTy:" device.

A device driver may be capable of supporting more than one open expansion channel at a time. In order to distinguish the channels, a qualifier can be added to the open request as part of the device name. It is then up to the device driver to specify the format of the qualifier. By convention, channels are allocated a single character sequentially from the character 'A'. For example, the parallel port driver can support two open channel, 'A' and 'B'. The LDD requires one of these qualifiers in order to open a parallel driver channel:

p_open(&pcb, "PAR:A", -1) p_open(&pcb, "PAR:B", -1)

The number of channels that can be thus supported will in general be dependent on the host SIBO hardware. In the case of the serial port on the S3a, for instance, only one SIBO channel can legitimately be opened corresponding to expansion port C. With the Workabout and HC, however, it is possible to open up to three separate SIBO channels on ports A through to C where A refers to the top port of the host machine, B to the bottom port and C to the side (or cradle) port.

LDDs have been designed to be accessed via the I/O system. I/O requests on the opened channel will reach the 'strategy vector' of the device driver. PDDs have been designed to be accessed by an LDD

Revision 1.00 Page 38 of 115 pages

The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

either via far calls or the Devvector OS system service. Once a channel has been obtained on a device driver, the operating system can send it events not sent to other applications. Examples are events generated by the machine being switched on or off, memory segments being moved about and the owning application being panicked. The EPOC OS can handle a maximum of 32 device drivers on a Series3 machine and 48 on other machines.

Loadable Logical Device Driver Structure

Common features of the structure of loadable LDDs

All loadable LDDs must conform to the following rules:

e There must be a single code segment and no data segments. The code segment is encapsulated in the assembler .asm file by calls to the codeSeg and EndCodeSeg defines respectively.

e The code segment must begin with a LibEnt structure which indicates the LDD name or signature which is used to identify the driver when trying to open and close channels.

e There must be at least eight supported functions which are listed in the LibEnt struc.

LibEnt Structure

The first field of the LibEnt structure consists of a two-byte signature containing the define ‘LDDSignature’ or 'PDDSignature’ in the case of a PDD. The remaining fields consist of an eight byte name which holds the device driver name stored as a zero terminated string (note that the trailing colon is omitted), a two byte vector count which must be at least eight and a vector table listing the supported device driver functions. The relevant code in the case of a hypothetical DevFunc LDD (DEVFUNC.LDD) with the device name of "TES:" is listed below:

CodeSeg

ProcBegin@ DevFuncLDD

dw LDDSignature db 'TES',0,0,0,0,0 dw (VectorEnd-Vector) /2 Vector: dw DevFuncInstall dw DevFuncRemove dw DevFuncHold dw DevFuncResume ; Mandatory LDD vectors dw DevFuncReset ; must be in this order dw DevFuncUnits dw DevFuncOpen dw DevFuncStrategy VectorHandler: dw DevFuncHandler ; Optional LDD vectors InterruptVectors: dw DevFuncTickInt VectorEnd:

ProcEnd noret The vector table contains the offsets within the device drivers code segment for the functions required

by the EPOC operating system which must be entered in the order shown. Note that in this document, the terms vector and function are used interchangeably.

Mandatory LDD Functions

All LDDs must support the following eight functions:

@ DevFuncInstall called on device installation

@ DevFuncRemove called on device removal

@ DevFuncHold called to temporarily disable the driver

@ DevFuncResume called to enable the driver after it has been temporarily disabled

Revision 1.00 Page 39 of 115 pages

The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

@ DevFuncReset called when an application terminates without closing the channel @ DevFuncUnits called to query the number of supported units (i.e. channels)

@ DevFuncOpen called to open a channel to an LDD

@ DevFuncStrategy called to access the driver's functionality from the I/O system

All of the eight mandatory routines pointed at by the function vector table will be called FAR by the operating system and should therefore use a FAR return machine code instruction to return control back to the OS. Since the FAR return address is to the OS it does not matter if the OS moves memory whilst code in the LDD is being executed: the OS cannot move its own code.

DevFunclinstall

This function is called by the operating system when the device driver is loaded in order to initialise any internal variables. It should not be called directly by an application process. The DevInstall operating system service will cause this function to be called. Applications should not call this service directly and should call instead the DevLoadLDD service.

An installable device driver may have the same name as a resident device driver. When the operating system loads a device driver, it places it at the end of the device driver table. The operating system will search this table for the appropriate device driver when it wishes to establish a channel. The search starts at the end and thus will locate the most recently installed device driver (if any) or if not, the resident driver. By this mechanism an installable driver can replace any resident driver.

When called, the DS and ES segment registers are in an unknown state. The device driver should take whatever steps necessary to obtain direct addressability to its data. For loadable device drivers this involves setting the DS and ES registers to the CS register or more commonly just using the CS override. The operating system will not move memory whilst in this function, thus the normal rules governing DS and ES may be ignored. All operating system services may be called, except those concerning file or device access.

PASSED

No values are passed to the install vector.

RETURN

If the installation was successful, return with the carry flag clear.

If the installation failed, return with the carry flag set and the error number in the AL register. PANIC

The install vector must not panic: it will cause an operating system kernel fault if it does. PRESERVE

The SS, SP and BP registers must be preserved by the install function.

DevFuncRemove

This function will be called by the operating system when the device driver is requested to be unloaded. It should not be called directly by an application process. The DevRemove operating system service will cause this function to be called. Applications should not call this directly, they should use the DevDelete service. Before the remove function is requested, the device driver will have received a hold request. Thus devices will only ever be removed when in a held state. If the device driver is currently busy serving a client, the remove request should return an error. Note that all resident device drivers will return an error since there is no mechanism by which they can be re-installed.

When called, the DS and ES segment registers are in an unknown state; the device driver should take whatever steps necessary to obtain direct addressability to its data. For loadable device drivers this involves setting the DS and ES registers to the CS register. The operating system will not move memory whilst in this function, thus the normal rules governing DS and ES may be ignored. All operating system services may be called inside the remove vector, except those concerning file or device access.

PASSED

No values are passed to the remove vector.

RETURN

If the remove was successful, return with the carry flag clear.

If the remove failed, return with the carry flag set and the error number in the AL register.

Revision 1.00 Page 40 of 115 pages

The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

PANIC

The remove vector must not panic: it will cause an operating system kernel fault if it does. PRESERVE

The SS, SP and BP registers must be preserved by the remove vector.

DevFuncHold

This vector will be called by the operating system when a logical device driver is requested to be held. The hold vector is called in the context of the operating system so DS and ES are not available. The DevHold operating system service will cause this vector to be called. Applications should not call this service. Physical device drivers cannot invoke holds and resumes. The operating system will call the hold vector under three conditions:

e Device memory segments are about to be moved.

e The machine is about to switch off due to the auto switch off time-out or user request, it enters the standby state.

e The machine is about to switch off due to the power source being removed.

It should be noted that holds and resumes are called on a per driver basis and so the corresponding driver code must deal with all the currently open channels. In all cases the device driver must respond to the request as quickly as possible. It must also ensure that ALL interrupts from the hardware device that it is driving are disabled. Device memory segments can only be moved if an installable device driver is being installed or removed. If the LDD uses an attached PDD and uses the faster FAR call mechanism to call the PDD strategy vector, the PDD strategy vector address will potentially move, thus the FAR address will be wrong. This address can be resolved in the resume vector. The LDD must not call the PDD between a hold and resume. Typically, the device driver only needs to disable its interrupts. When a resume occurs, the device driver should continue as though nothing had happened.

If the machine is about to switch off due to the auto switch off or user request mechanisms (enter the standby state), the device driver should make an orderly shut down of the device such that the state before the shut down can be recovered when the system powers up again. The device driver should also attempt to ensure that no data is lost. For example, in the serial driver the current state of the hardware handshaking lines should be noted so that each state can be restored on power up. For this type of power down the hold vector is allowed to take a significant length of time to shut down a device. For example in a serial driver the hold vector should wait until the remote end stops transmitting data after any hardware handshaking has been applied. Of course, the time taken should be kept to a minimum: in the case of the serial driver above the time is roughly equivalent to 3 character transmission times. When a resume occurs the device driver should continue as though nothing had happened.

If the machine is about to switch off due to the power source being removed, the device driver should reset the device in the minimum possible time: no attempt should be made to perform an orderly shut- down. The device driver is not expected to be able to recover the hardware state. When a resume occurs, the device driver would typically fail any outstanding application requests. If the hold vector takes too long the voltage will fall below the threshold to hold the state of the internal RAM. If this occurs the machine will perform a warm re-boot when powering up, all data in the internal memory of the machine will be lost including the device driver code! On power fail there is about 2ms available to power down all devices.

On a power failure hold, the operating system will already have sent a 'reset' to all the SIBO serial channels. Any device drivers using these channels need only record the hold reason for the resume vector. Any other peripherals should be designed to allow a power fail mechanism with the minimum amount of code. It must be noted that the power fail type hold can occur whilst the device driver is in the memory move hold state. In this case, the device driver will receive two hold requests before seeing a resume request. A device driver must be capable of handling this. In this case, the device driver will also receive two resume requests. A device driver will not get a power fail hold whilst in

Revision 1.00 Page 41 of 115 pages

The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

power down hold. A call to the hold vector will always be followed by a call to the resume vector (except when a device is requested to be removed).

Note that with the Series 3a and Workabout, there is an additional case when hold and resume must be invoked and that is on opening/closing of the pack doors. In this case, the LDD must generate its own Hold and Resume. This situation is examined in more depth in the context of the specific example drivers presented later in this document.

When called, the DS and ES segment registers are in an unknown state; the device driver should take whatever steps necessary to obtain direct addressability to its data. For loadable device drivers this involves setting the DS and ES registers to the CS register. The device driver should not call any operating system services in the hold vector code due to the time taken, especially on power failure. PASSED

The AH register takes one of the following

@ DevHoldNormal Device memory is about to be moved. @ DevHoldPowerDown The system is about to enter the standby state. @ DevHoldPowerFail The system has lost its power supply. RETURN None. PANIC

The hold vector must not panic: it will cause an operating system kernel fault if it does. PRESERVE The SS, SP and BP registers must be preserved by the hold vector.

DevFuncResume

This vector will be called by the operating system when the device driver is requested to be resumed. The resume vector is called in the context of the operating system. The DevResume operating system service will cause this vector to be called. Applications should not call this service. The resume vector will be called either when memory has finished being moved or when the machine powers back up. In both cases the hold vector will have been called before this vector is called. The device driver is expected to recover from the previous hold request (except power fail) and resume any I/O that was suspended. If the device driver has an interrupt service routine, it should reset the interrupt service routine's address since the device driver may have moved in memory; its absolute segment address will be different.

If the hold was a device memory segment move type hold, interrupts should be re-enabled. If the LDD uses an attached PDD and uses the FAR call mechanism to access the PDD strategy vector, the address of the PDD should be reset by using the DevGet PDDAddress operating system service before enabling interrupts. Typically, the PDD will have a call back to the LDD and it needs to be informed of the change of address of the LDD call back function, the LDD-PDD interface definition should allow such a function request.

If the hold was a power down type hold, the resume vector needs to power up the peripheral and set it to the state that it was in before the power down occurred. If this is not possible or data has been lost, the device driver should inform any outstanding requests of this fact. It is also possible that the hardware device that the driver is associated with has been removed. The driver should be able to handle this properly. If the device driver is expected to generate events due to an external state change, the driver should check the external state and generate appropriate events. For example, the serial driver may be requested to inform an application when the DTR line changes state. The remote end may have changed the state of DTR whilst the driver is held.

If the hold was a power failure type hold, the resume vector should power up the peripheral and put it

into a known state, preferably the state that the application software thinks that the device is in and fail any outstanding requests as data is quite likely to have been lost.

Revision 1.00 Page 42 of 115 pages

The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

When called, the DS and ES segment registers are in an unknown state. The device driver should take whatever steps necessary to obtain direct addressability to its data. For loadable device drivers this involves setting the DS and ES registers to the CS register. All operating system services may be called, except those concerning file or device access.

PASSED

None

RETURN

None.

PANIC

The resume vector must not panic, it will cause an operating system kernel fault if it does. PRESERVE

The SS, SP and BP registers must be preserved by the resume vector.

DevFuncReset

This function will be called by the operating system when the device driver is requested to reset a channel. The reset function is called in the context of the operating system so DS and ES are not available. The device driver must request that the operating system call the reset function. This is achieved by calling the IoRequestReset system service, usually in the open vector. To cancel this request, the device driver should call the IoRequestResetCancel system service. The cancel service is usually called as part of the close functionality in the strategy vector. The reset vector will be called when the operating system is tidying up resources owned by a process that has terminated. Ifa process terminated before it closed the device driver channel and no reset service is requested, that channel would remain allocated; no process will ever close the channel. The reset vector allows a device driver to reset itself and allow the channel to be opened again. Any data required to perform the reset must be stored in the device driver. The data space belonging to the process that originally opened the channel has been returned to the operating system memory pool and is no longer valid. If a device driver can handle multiple channels then the data passed to the IoRequestReset system service should identify the channel. This data will be passed in the CX register to the reset vector. The device driver should only have a reset request outstanding with the operating system while a process has a channel open.

When called, the DS and ES segment registers are in an unknown state; the device driver should take whatever steps necessary to obtain direct addressability to its data. For loadable device drivers this involves setting the DS and ES registers to the CS register or using CS override. All operating system services may be called, except those concerning file or device access.

PASSED

This function is passed data in the CX register that the device driver requested it be sent to determine which channel should be reset.

RETURN

None.

PANIC

The reset vector must not panic; it will cause an operating system kernel fault if it does.

PRESERVE

The SS, SP and BP registers must be preserved by the reset vector.

DevFuncUnits

This function will be called by the operating system when the device driver is requested to report the number of units (i.e. channels) the device driver can support. This function is called in the context of the operating system. The operating system places no significance on the number of channels a device driver can support. It is primarily used for informational purposes. An application may use the number of units to attempt to open any available channel on that device driver.

When called, the DS and ES segment registers are in an unknown state; the device driver should take whatever steps necessary to obtain direct addressability to its data. For loadable device drivers this involves setting the DS and ES registers to the CS register. All operating system services may be called, except those concerning file or device access.

PASSED

Revision 1.00 Page 43 of 115 pages

The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

None.

RETURN

The AX register should contain the number of channels supported. If a device driver can support multiple channels (limited only by memory constraints) then the driver may return -1. A serial device driver, for example, might only support two channels (TTY:a and TTy:8) whereas the file device driver can open an unlimited number of files.

PANIC

The channels units vector must not panic; it will cause an operating system kernel fault if it does. PRESERVE

The SS, SP and BP registers must be preserved by the units vector.

DevFuncOpen

This function will be called by the operating system when a channel to the device driver is required to be opened. This function is called in the context of the process that called the Ioopen system service. This means that DS and ES point to the application data space. The device driver is passed two parameters, its device handle and a pointer to an OpenEnt structure. The device handle is the entry in the system device table of this device driver. The device driver is required to place this handle in the ChanLibHandle field of the ChanEnt structure which must be allocated in the user's data space. The operating system uses the device handle to route any I/O requests on the opened channel to the correct device driver.

The OpenEnt structure contains three fields, openNamePtr, OpenMode and OpenChan.

The openNamePt r field contains a pointer to the character that exists after the device name as passed to the ToOpen system service. For example, if the ToOpen service was passed a name of PAR:A, the OpenNamePtr field would point to the colon. If the ToOpen service was passed a name of TTY.AS5:B the OpenNamePtr field would point to the full stop. The device driver should process the name appropriately, opening the correct PDD as required.

The OpenMode field contains the mode for opening the device driver. The available modes are specified by the device driver writers. For example, a combined Xmodem and Ymodem device driver could use the mode to specify whether the Xmodem or the Ymodem protocol is to be used.

The Openchan field contains the I/O channel handle of the device that this driver is required to ‘attach’ to. Attached device drivers are dealt with later in the chapter.

The code in a device driver open vector tends to follow a very similar pattern. This is demonstrated by the following code fragments and associated comments. The first stage is to allocate some data space in the calling process' heap space. This will contain the I/O channel control block:

mov cx, (size DeviceEnt)

HeapAllocateCell

jc noMemory

mov bx, ax ; cell handle

If the device driver requires a WaitHandler (described later):

mov al, (VectorHandler-Vector) /2 ToAddHandler

jc endFreeMemory

mov [bx].DriverHandler, ax

If the device driver's DevFuncReset vector is required to be called:

push bx

mov cx, ChannelIndicator 7 unique per channel mov bx, ax ; the device handle ToRequestReset

pop bx ; restore alloc cell

The chanEnt field of the DriverEnt structure must be initialised:

mov [bx] .DriverIo.ChanNext, bx mov [bx] .DriverIo.ChanSignature, IoChanSignature mov [bx] .DriverIo.ChanLibHandle, dx

The ChanNext field is used by attached drivers and will usually be set to be the allocated cell handle of the device driver being opened. The IoFuncattach and IoFuncDetach functions manipulate these fields. The I/O system uses this field to direct the I/O request to the correct driver.

Revision 1.00 Page 44 of 115 pages

The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

The ChanSignature field is checked by the operating system during any I/O requests for the value IoChanSignature. If it does not contain that value, the process calling the I/O service will be panicked for having passed an invalid I/O channel handle.

The ChanLibHandle field is used by the operating system to route an application's I/O request to this device. The I/O request will call the DevFuncstrategy vector of the device driver.

If the driver is an attached driver the following is required:

mov cx, bx ; allocated channel

mov bx, [si] .OpenChan ; channel attaching to mov al, IoFuncAttach ; return in BX the ToWithWait ; channel attached to

Finally, if the channel has been successfully opened: ele Opened Ok ret return BX and DX

The error recovery code typically follows the following pattern:

endFreeReset: push ax push bx mov cx, ChannelIndicator mov bx, ax ToRequestResetCancel pop bx pop ax endFreeHandler: push ax push bx mov bx, [bx] .DriverHandler ToRemoveHandler pop bx pop ax endFreeMemory: push ax HeapFreeCell pop ax stc noMemory: ret

If a device driver supports a fixed number of channels, it typically contains static control blocks. In order to determine if a requested channel is currently open, a field should be interrogated. The device driver should ensure that interrupts are disabled during this sort of check since a context switch could occur and another process request the opening of the same channel. This is the classic 'test and set' problem encountered in multi-tasking environments.

When called, the DS and ES segment registers point to the data segment of the application process attempting to open a device channel. The application should ensure that the DS and ES segment registers do in fact point to its data segment. The device driver must obey the normal rules concerning segment register manipulation. The DS and ES segment registers can be reloaded if required from the IntEnt structure pointed at by the BP register. All operating system services may be called.

PASSED

DX contains the device handle of the device driver.

SI is a pointer to the OpenEnt structure

BP is a pointer to the IntEnt structure.

RETURN

If the channel open was successful, return with the carry flag clear and the BX register containing the open channel.

If the open failed, return with the carry flag set and the error number in the AL register.

PANIC

The open vector can panic; it will cause the process requesting the device open to terminate. It is however more usual to return an error to the calling process.

PRESERVE

The DS, ES, SS, SP, BP and DX registers must be preserved by the open vector.

Revision 1.00 Page 45 of 115 pages

The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

DevFuncStrategy

When an application makes an I/O request on the opened device driver channel the request is routed to this vector by the operating system. A device driver defines the set of functions that it supports. These typically include IoFuncSet, IoFuncSense, IoFuncRead, IoFuncWrite and IoFuncClose. A device driver does not have to support any particular function, as it is a matter of design between a device driver writer and application writer as to what functions and associated parameters are provided. To obtain the power of attached device drivers, however, it is recommended that the device driver use the system defines with their appropriate functionality, for example, the loFuncWrite function number should always be associated with writing data.

The strategy function is passed the channel handle as allocated in the open vector in the BX register. This typically contains control information concerning the current state of the I/O channel.

The SI register contains a pointer to a RgEnt structure. This structure contains four fields, RqFunction, RqStatusPtr, RqA1Ptr and RqA2Ptr.

The RgFunction field contains the function number as passed to the IowithWait (or IoAsynchronous) I/O request by the application. If a device driver does not support the specified function, it should pass the request on to its 'parent' device driver.

The RqStatus pointer contains a pointer to a memory location in the application process's data space that receives the I/O requests completion status. The device driver must set this memory location to the value PendingErr whilst the I/O request is outstanding and a completion code when the I/O request completes. An I/O request may complete within the strategy vector or it may complete some time in the future, presumably from some interrupt.

The RgA1Ptr and RqA2Ptr fields contain the argument | and 2 parameters as passed to the IoWithWait (or IoAsynchronous) system services. The device driver is free to specify what these parameters are (if any).

The operating system defines a set of common function numbers used by device drivers referred to as the IoFuncxxx set of defines. By convention, a device driver should select from this list, particularly if some of the more advanced features of the I/O system are to be used, such as attached device drivers. The more common defines are listed below:

@ ToFuncRead ; read from the device.

® TfoFuncWrite ; write to the device.

@ TloFuncClose ; close device channel.

@ = =ToFuncCancel ; cancel an I/O request.

® ToFuncSet ; set driver characteristics.

® tloFuncSense ; sense driver characteristics. e lIoFuncFlush ; flush any buffers.

The PLIB library functions p_read, p_write and p_close will call the device driver with the IoFuncRead, IoFuncWrite and IoFuncClose function numbers. Thus, if the device driver chooses an alternative function number set, an application will not be able to use the supplied library functions. All resident device drivers obey the following conventions: e Acancel request will cancel any outstanding requests. A cancel request will not return any error.

e Aclose request will ensure that any outstanding requests are completed before closing the channel. A close request will not return any error.

e Only one request of a particular type can be outstanding at any one time. If a second request is made the device driver will panic the calling application.

Any functions that the strategy function does not support should be passed on to the next driver down the driver hierarchy. If the driver is a root driver (attached driver), this is achieved using the IoRoot

Revision 1.00 Page 46 of 115 pages

The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

(IoSuper)system service. If the requested function is not supported by any driver, the operating system will return a Not Supported error.

When called, the DS and ES segment registers point to the data segment of the application process making the I/O function request. The application should ensure that the DS and ES segment registers do in fact point to its data segment. The device driver must obey the normal rules concerning segment register manipulation. The DS and ES segment registers can be reloaded if required from the IntEnt structure pointed at by the BP register. All operating system services may be called. PASSED

BX contains the allocated channel control block.

DX contains the device handle of the device driver.

SI is a pointer to the RqEnt structure.

BP is a pointer to the IntEnt structure.

RETURN

If the function request is successful, the strategy vector should return with carry clear. A request typically causes some I/O. If the I/O is completed by the strategy vector (i.e. the request is for a synchronous function such as close), the completion status should be written back to the RqStatusPtr location and the I/O semaphore signalled (using the IoSignal system service). If the request has not yet completed (i.e. the request is for an asynchronous function), the RqStatusPtr location should contain the value PendingErr and the I/O semaphore should not be signalled.

If the function request failed the strategy vector should return with carry set and the error code in AL. In this case, typically no I/O requests will be completed.

PANIC

The strategy vector can panic; it will cause the process making the I/O request to terminate. In most cases it is usual to return an error to the calling process. A major exception to this is if the calling process makes an I/O request of the same type as one that is currently outstanding and the device driver only supports one I/O request of a particular type at a time; by convention the device driver should panic the calling process with the PanicIoPending panic code.

PRESERVE

The DS, ES, SS, SP and BP registers must be preserved by the strategy vector.

Interrupts and Interrupt Service Routines

Device drivers that talk to hardware tend to have interrupt service routines associated with them, especially if they are receiving data from an external source. The EPOC operating system provides a framework within which an interrupt service routine can be written relatively easily. An interrupt service routine is a code section that is called by the OS in response to a particular hardware event. As indicated in the Hardware Overview, the SIBO architecture allows for eight independent hardware interrupt sources, some of which are pre-allocated to system components. The operating system provides the GenSetRevector service to allow a device driver to install an interrupt service routine for any of the eight hardware interrupt sources. This call passes the interrupt vector (the address of the interrupt service routine) and the interrupt number (which is dependent on the host hardware) to the OS so that it knows where to jump to when the interrupt occurs. A device driver should use this system service and not poke directly into the 8086 interrupt vector table. The address passed to the GenSetRevector Service is not written into the interrupt vector table but to an internal table. After invoking this service, the desired interrupts must be masked in by writing the appropriate mask to the mask register. Initially, of the eight interrupt sources, only the tick interrupt is masked in.

When an interrupt occurs, the microprocessor could be running any currently active process. The OS handles the servicing of interrupts by building a mandatory operating system call frame. All CPU registers are preserved on route. The interrupt service routine is then called as a FAR routine. Since the operating system preserves all registers the interrupt service routine is free to use any register. As with all interrupt service routines various rules apply:

e Interrupt service routines should execute as fast as possible. Operating system interrupt service routines are tuned to last no longer than one millisecond.

Revision 1.00 Page 47 of 115 pages

The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

e Typically, interrupt service routines do not enable interrupts unless the routine can handle re- entrancy.

e Interrupt service routines run in the context of whatever process is running at the time of the interrupt. An interrupt service routine should not attempt to obtain admissibility to the process that opened the channel but access the internal driver space only which in general is its own code space.

e An interrupt service routine must not directly cause the OS to reschedule the running process as this would significantly delay its completion. It must use the IoSignalByPidNoReSched system service in order to indicate to the handler that an event has occurred to the owning process. The handler function of the device driver must pick up the event and inform the owning process.

e An interrupt service routine should return with the carry flag clear if it requires a reschedule to occur (it has called IoSignalByPidNoReSched) otherwise return with the carry flag set. This will cause the operating system to reschedule if the internal state allows such an action otherwise the reschedule request is effectively queued until such time that the operating system can reschedule.

At some stage during the course of an interrupt service routine, it is necessary to clear the interrupt line with some hardware-specific action. Then the interrupt controller inside the host ASIC1 or ASIC9 has to be cleared with a write to the NonSpecificEoi location. To remove the interrupt service routine address, the operating system service GenResetRevector should be used. This will reset the internal table entry to the default held in the ROM. Additionally, the interrupt mask should be reset to the original value.

Device Driver I/O Semaphore Wait Handlers

An LDD may nominate one of its functions to be called by the operating system every time the I/O semaphore of the process that opened the channel is signalled. The nominated function, known as the wait handler, will only be called if the application is waiting for an outstanding I/O request to complete. For well written applications this is practically all the time. By convention the vector table entry after the mandatory vectors contains the handler vector. A handler routine is similar to an interrupt service routine in that it appears to run ‘from nowhere’. Comparing handlers and interrupt services routines shows that:

e A handler will always run in the context of the process that has opened a channel. An interrupt service routine will run in the context of whatever process happens to be running at the time of the interrupt.

e A handler can access the data space of the process that opened the channel. The interrupt service routine must not. An interrupt service routine should only access the data space in the driver which is usually its own CS space.

e A handler can cause a reschedule. An interrupt service routine must not cause a reschedule. If it did, the interrupt would not be fully serviced (the rest of the interrupt service routine would not be executed until a reschedule back to the process running at the time of the interrupt, which may not happen for a significant length of time). The interrupt service routine must only use the IoSignalByPidNoReSched to signal the channel owner.

The handler is the mechanism by which hardware interrupt events can be filtered through to the process using the I/O channel. Typically, it is in the handler code that the 1oSignal signifying completion of an asynchronous I/O request is invoked.

Loadable Physical Device Driver Structure

A loadable PDD must obey the following rules: e There must be a single code segment and no data segments.

Revision 1.00 Page 48 of 115 pages

The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

e The code segment must start with a LibEnt structure. e There must be at least two supported functions, with typically a further two defined.

Single Code Segment

A PDD must be written to contain any internal variables within its own code segment. Typically, these variables are only concerned with unit (i.e. channel) allocation and hardware state. Data space for a particular open channel can be allocated in the heap space of the process that opens the device. This data space will however disappear if the process terminates, thus any variables required for ‘freeing’ the hardware after a process terminates must exist in the code space of the device driver.

The LibEnt Structure

A LibEnt structure has the following format: e =A two byte signature

e §=6©An eight byte name e A two byte vector count e A vector table

The two byte signature should contain the 'PDDSignature' define. The eight byte name contains a zero terminated name, being that of the device driver. Note that there is no trailing colon. The two byte vector count contains the number of vectors that follow immediately after the count. There should be at least two. For example:

dw PDDSignature ; Its an PDD driver

db "DVR.HW1',0 ; Name of the driver

dw (VectorEnd-Vector)/2 ; Number of vectors Vector:

dw DvriInstall ; Install vector

dw DvrRemove ; Remove vector VectorEnd:

Most PDDs also define a further two vectors: dw DvrOpen , Open Vector dw DvrStrategy ; Strategy vector

The table of vectors is a table of offsets within the device drivers code segment of the routines that implement the required functionality. The vector table must have the entries in the order shown in the example.

Mandatory PDD functions

All PDDs must support the following two functions: @ DevFuncInstallppp called on device installation.

@ DevFuncRemovePDD called on device removal.

Most PDDs will support the following two additional functions: @ DevFuncOpenPDD called to open a PDD.

@ DevFuncStrategyPDD called to provide PDD functionality.

All of the routines pointed at by the function vector table will be called FAR by the operating system and should consequently use a FAR return machine code instruction to return back to the operating system. Since the FAR return address is to the operating system, it does not matter if the operating system moves memory whilst code in the LDD is being executed; the operating system cannot move.

DevFunclnstallPDD

This vector will be called by the operating system when the device driver is loaded to initialise any of its internal variables. The install vector is called in the context of the operating system and not the process that is loading the device driver. The DevInstall operating system service will cause this

Revision 1.00 Page 49 of 115 pages

The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

vector to be called. Applications should not call this directly, they should use the DevLoadPDD service.

An installable device driver may have the same name as a currently installed device driver. When installed, the driver is added to the end of the device driver table. When a channel to a device driver is being established by the operating system, it searches the device table from the end first, thus the latest installed device driver with the required name will be asked first for a channel. So as with LDDs by this mechanism installable device drivers can replace any of the resident drivers.

When called, the DS and ES segment registers are in an unknown state. The device driver should take whatever steps necessary to obtain direct addressability to its data. For loadable device drivers this involves setting the DS and ES registers to the CS register. The operating system will not move memory whilst in this function, thus the normal rules governing DS and ES may be ignored. All operating system services may be called except those concerning file or device access.

PASSED

No values are passed to the install vector.

RETURN

If the installation was successful, return with the carry flag clear.

If the installation failed, return with the carry flag set and the error number in the AL register. PANIC

The install vector must not panic; it will cause an operating system kernel fault if it does. PRESERVE

The SS, SP and BP registers must be preserved by the install vector.

DevFuncRemovePDD

This vector will be called by the operating system when the device driver is requested to be unloaded. The remove vector is called in the context of the operating system and not the process that requests the unload. The DevRemove operating system service will cause this vector to be called. Applications should not call this service directly; instead, they should call the DevDelete service. Before the remove function is requested, the operating system will send a DevFuncHold request to all LDDs. The LDD is responsible for ensuring that no activity will occur during the remove. Note that any device driver that handles hardware interrupts must contain an LDD since only LDDs receive a hold request. If the device driver is currently busy serving a client, the remove request should return an error. All resident device drivers will return an error since there is no mechanism by which they can be re-installed.

When called, the DS and ES segment registers are in an unknown state; the device driver should take whatever steps necessary to obtain direct addressability to its data. For loadable device drivers this involves setting the DS and ES registers to the CS register. The operating system will not move memory whilst in this function, thus the normal rules governing DS and ES may be ignored. All operating system services may be called except those concerning file or device access.

PASSED

No values are passed to the remove vector.

RETURN

If the remove was successful, return with the carry flag clear.

If the remove failed, return with the carry flag set and the error number in the AL register. PANIC

The remove vector must not panic; it will cause an operating system kernel fault if it does. PRESERVE

The SS, SP and BP registers must be preserved by the remove vector.

DevFuncOpenPDD

This function is defined as a convenience function for the LDD-PDD interface. When an application opens a channel to an LDD, it normally uses the Ioopen system service. If the name specifies, or the LDD requires, a PDD then it needs to open a channel toa PDD. The Devopenppp system service will call this PDD vector to establish a channel. The LDD now has a choice of calling a PDD vector using the DevVector system service or calling the fourth vector in the vector table directly. The fourth

Revision 1.00 Page 50 of 115 pages

The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

vector is assumed to be a strategy vector to which any parameters as required by the LDD-PDD interface can be passed. The FAR address of the strategy vector is returned by the DevGetPDDAddress. When an LDD receives a DevFuncResume it should call DevGet PDDAddress again to ensure that if the PDD has moved the LDD still has its correct address. As a design, a PDD could provide many vectors, one for each required function. The LDD would then use the Devvector system service to access each of these functions. The DevGetPDDAddress will only return the FAR address of the fourth vector.

When called, the DS and ES segment registers point to the data segment of the application process making the open function request. The application should ensure that this is indeed the case. The device driver must obey the normal rules concerning segment register manipulation. All operating system services may be called.

PASSED

The BX register contains a pointer to the PDD unit name. The pointer passed to the DevOpenPDD service is used to find the PDD device to open. The BX register is loaded with a pointer to the trailing colon (if any) in the PDD unit name. For example if the name "TTy.AS5:A" was passed to the DevOpenPDD service, BX would contain a pointer to :A upon calling the open vector. RETURN

If the open was successful, return with the carry flag clear.

If the open failed, return with the carry flag set and the error number in the AL register.

PANIC

The open vector can panic; it will cause the process requesting the device open to terminate. It is however more usual to return an error to the calling process.

PRESERVE

The SS, SP and BP registers must be preserved by the open vector.

DevFuncStrategyPDD

This function is defined as a convenience function for the LDD-PDD interface. Typically, all application function requests are routed through the strategy vector. To speed the calling interface, the DevGet PDDAddress operating system function will return a FAR address of this vector. The device driver writer defines all the functions and return values as required.

When called, the DS and ES segment registers point to the data segment of the application process making the function request. The application should ensure that the DS and ES segment registers do in fact point to its data segment. The device driver must obey the normal rules concerning segment register manipulation. All operating system services may be called.

PASSED

The parameters passed are defined by the device driver write.

RETURN

All returns are defined by the device driver writer.

PANIC

The strategy vector can panic; it will cause the process requesting the function to terminate. It is however more usual to return an error to the calling process.

PRESERVE

Which registers are preserved is defined by the device driver writer.

Revision 1.00 Page 51 of 115 pages

The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

10. ASIC4/ASIC5 BASED DEVICE DRIVERS

Introduction

This chapter describes the rules and problems involved in writing a device driver that controls some form of ASIC4 or ASICS based hardware. Details concerning the internal organisation of these ASICs were presented earlier in chapters 6 and 7. The emphasis is on their use for Series 3a applications, though most issues that will be discussed also apply to the Series 3, MC and HC range of Psion products.

In addition to the eight mandatory functions already detailed in the Device Driver Overview chapter, an LDD will usually provide additional functionality in the form of further vector table entries dependent upon the requirements of its application. Wherever possible, these functions should make use of the various pre-defined system defines for services such as reading (p_read) and writing (p_write) etc. It should be noted that there is no particular requirement to implement a device driver as a separate PDD and LDD and in the case of the example logical device driver A4EXIF.LDD, the approach taken is to incorporate both aspects into the one LDD.

SIBO Hardware Expansion Channels

The number of SIBO expansion channels supported by the host machine will vary according to the particular Psion hardware present. So that a single device driver may be compiled for the different host machine possibilities, a number of build flags can be used to set various constants within the include files. The hardware options are outlined in the table below:

SIBO Machine Flags | Number of SIBO serial channels supported Machine Build Flag

Consumer (S3a) Refers to $3a with ASIC9 only. Supports 1 SIBO channel (A)

ES ae Mat AST lysed SPS PTT

It should be noted that Psion device drivers should be designed to be easily adapted from machine to machine. For a well-written driver, the only change that needs to be made in adapting it for use on another Psion machine is the alteration of the build flag at the start of the code. This flag indicates to the compiler which SIBO machine flags as well as other variables should be set for the host machine. The four most important SIBO machine variables are the channel interrupt mask, the channel interrupt number, the channel interrupt vector and the hardware SIBO channel. The channel interrupt mask is an eight bit value or'd with the contents of either AlInterruptMask or A9BInterruptMask (the mask registers) to initiate interrupts on the relevant channel depending on whether the interrupt controller resides in ASIC1 or ASIC9. If this mask is then used in a HwGetChannel call, any hardware interrupts on the selected expansion channel will be directed to the appropriately coded interrupt service routine. The channel interrupt mask is also required in the subsequent HwFreeChannel OS service call and when stopping hardware interrupts. The channel interrupt number is a sixteen-bit quantity required by the GenSetRevector and GenResetRevector OS system services to indicate to the OS which default interrupt service routine is to be replaced by the suitably coded device driver interrupt vector. The channel interrupt vector is a sixteen-bit pointer to the location of that interrupt vector in the device driver code. Finally, the hardware SIBO channel is used by the HwSelectChannel OS service to direct any SIBO serial control or data frames

Revision 1.00 Page 52 of 115 pages

The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

along the appropriate channel. The situation regarding the value of these variables for the expansion ports on all current SIBO platforms is illustrated in the table overleaf:

IW orkabout (Series3) a en en an Channels

Controller ASIC |ASIC? ASICO Mask Register A9BInterruptMaskRW a a a ae

IHwIrq2Revector

mask A9MExpIntA (Expansion Port A) mask A9MExpIntB (Expansion Port B) Imask AOMSlave

(Expansion Port C)

IHwIrq4Revector IHwIrgq5Revector IHwIrq2Revector

ASIC2

mask ExpIntLeftA (Expansion Port A) mask ExpIntRightB (Expansion Port B) mask Asic2Int (Expansion Port C)

IHwIrgq3Revector IHwIrq2Revector IHwIrq4Revector

ASIC2 ASIC2

mask Asic2Int (Expansion Port C)

mask ExpIntLeftA

(Expansion Port A) mask ExpIntRightB (Expansion Port B)

IHwIrgq3Revector IHwIrq2Revector

IHwIrq4Revector

Ptr Channel SelectChannel5. SelectChannel3 IExpChannelLeftA IExpChannelLeftA SelectChannel7 Hard Select SelectChannel4 ExpChannelRightB = |ExpChannelRightB

arOWAre Dre’ SelectChannel5 SelectChannel7

Talking to ASIC4

All communication to an ASIC4 is via a Psion Serial Link. As explained in the chapter on the SIBO serial protocol, two forms of data can be sent and received along this channel. These are control and data bytes. Control bytes give specific instructions to ASIC4 and data bytes can either be data sent to or from ASIC4 or data given to or taken from peripheral chips in ASIC4's address space. Sending and receiving control and data frames down a Psion Serial Channel from a Series 3/HC host is simply a matter of IN and OUT instructions to various fixed I/O addresses. Various assembler macros have been set up to ease this task and provide machine independence and they are detailed in the appendix. These include:

SCONTOUT Output the control byte held in the AL register SDATAIN Input a byte of data and place it in AL

SDATAOUT Output the data byte in the AL register

XNOP Wait a short while

SBUSY Wait while the Psion Serial Link is busy

Once a piece of peripheral hardware has been designed the appropriate software must be written to control it. All hardware devices on Series 3/3a, Workabout and HC machines are controlled by device drivers. These act as an interface between a piece of hardware and an application that uses it. The following section goes into further detail regarding the methods by which a device driver is able to communicate with and thereby control an ASIC4 and ASICS based peripheral.

ASIC4 Registers

ASIC4 has eight registers and their functions in mixed (i.e. peripheral) mode are outlined below:

Register 0: This register is the read/write Data Register that controls the data lines DO-D7 which are normally in tri-state mode. Data written to the Data Register is output on DO-D7 during a write cycle and data input to the DO-D7 may be read from the register during a read cycle. On reset, this register holds the Info Byte and its bits have the following meanings:

Revision 1.00 Page 53 of 115 pages

The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

Bit No. D7 D6 DS D4 D3 D2 DI DO DD DN N S S _ S

D D_ OD i _ Device type

0 0 O RAM SSD

0 oO 1 Intel Flash type 1

0 1 O Intel Flash type 2

Oo 1 1 TBS

1 0 O TBS

1 0 1 TBS

1 1 0 Read only SSD (ROM OTP etc.) 1 1 1 Hardware Write protected SSD N N Number of devices

0 O 1

0 1 2

1 0O 3

| ae | 4

S S_ S__ Device Size

0 O O Illegal (Indicates no SSD present) 0 0 1 32Kbyte

0 1 O 64Kbyte

Oo 1 1 128Kbyte

1 0 O 256Kbyte

1 0 1 512Kbyte

1 1 O 1Mbyte

1 1 1 2Mbyte

Register 1: This register is both a read and write register. In read mode, it is termed the Input Register. The eight bits of this register are then defined as follows:

The Se, De and Ne bits hold, on reset, the Extended Info Byte which is used in ASIC4 Extended mode to define the type of peripheral device as explained later in the section on ASIC4 reset and configuration and outlined below:

M De Ne Se 1 0 0 90 No peripheral devices 1 0 O 1 Turbo RS232 serial (16550) 1 oO 1 O 3Fax 1 oO 1 1 T.B.S. 1 1 0O 0 T.B.S. 1 1 OO 1 T.B.S. 1 1 1 O T.B.S. 1 1 1 1 Extended info contained in ROM.

The X2 bit sets the state of the X2D2 input which is used to indicate whether the device size is correct. In M=0 mixed mode, the X2 bit must be low. Inputs In0-In2 hold the current status of the three correspondingly named general input lines to ASIC4.

In write mode, Register 1 is termed the Device Size Register where bits 3-0 (S3-SO) map to the settings of the decoder inputs (and hence the peripheral device size) as follows overleaf:

Revision 1.00 Page 54 of 115 pages

The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

Size Register Decoder Inputs Device Size (bytes) S3 S2 S1 SO DCO DC1 DC2

0 0 0 0 A15 Al6 Al7 32k

0 0 0 1 Al15 Al6 Al7 32k

0 0 1 =O Al6 Al7 A18 64k

0 oO 1 1 Al7 Al18 A19 128k 0 1 0 0 Al8 Al19 A20 256k 0 1 0 1 A19 A20 A21 512k 0 1 1 =O A20 A21 A22 1M

0 1 1 1 A21 A22 A23 2M

1 0 0 0 A22 A23 A24 4M

1 0 O 1 A23 A24 A25 8M

1 0 1 O A24 A25 A26 16M

1 oO 1 1 A25 A26 A27 32M

1 1 0 0 A26 A27 0 64M

1 1 0 1 A27 0 O 128M 1 1 1 = O 0 0 O 256M 1 1 1 1 0 oO O Not Used

This register defaults to OxOf on reset (i.e. not used).

Register 2: A write to this register , the Address Increment Register, will increment the addresses AO-A3.

Register3: This register is the write-only Address Register which controls all 28 address lines (AO- A27) directly and the eight chip selects (CSO-CS7) indirectly. The address register is written to in multi-transfer mode LSByte (ATO) first. There can be up to four bytes written:

Byte Address lines ATO AQ - A7 ATI A8& - Al5 AT2 Al6 - A23 AT3 A24 - A27

When the first byte is written, all the higher address lines (A8-A27) are reset to 0. Bits 4-6 of AT3 may be used by the internal address decoder to control the CS outputs CSO-CS3 if appropriate. On reset, all bits of this register are cleared.

Register 4, 5 and 6: Not implemented. Register 7: This register is the write only ASIC4 Control Register and holds the following bits:

Bit: 7 6 5 4 3 2 1 0 Label: LBO TSTA LTM VPS EDA CSS WRS OES

Setting the LBO and VPS bits causes the corresponding lines on ASIC4 to be set high enabling them to be used as general purpose outputs for peripheral development. OES and WRS control R/W accesses.

Additional ASIC4 Signals

InO, In1, In2 are general purpose digital inputs. LBO, VPS are general purpose digital outputs. OE, WR control Read/Write bus accesses. MCSD, X2D2 should be tied to ground via a 100k resister. POR is the reset line.

Revision 1.00 Page 55 of 115 pages

The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

Talking to ASIC5

The Psion serial protocol was designed to allow many different peripheral ASICs to lie on the same serial channel. Before software can communicate with an ASICS it must first be selected. ASICS must be selected in different ways depending on whether it has been configured (in hardware) to operate in either Pack or Peripheral mode. In addition to selecting ASICS when it is first used, ASICS must be re-selected whenever a hold and resume is generated due to power down, pack doors opening or when the peripheral is inserted or removed. ASIC5 will always respond to a select with a byte indicating what type of peripheral or pack it is. If there is no ASICS connected to the Psion serial link there will obviously be no response (zero is returned) and software must then take the appropriate action. To select a peripheral mode ASICS the following code can be used:

HwNullFrame

mov al, (SerialSelect or Asic5NormallId) SBUSY

SCONTOUT

XNOP

SBUSY

SDATAIN

test al,al

je NoASIC5PeripheralOutThere

To select a pack mode ASICS the following code can be used.

HwNullFrame

mov al, (SerialSelect or Asic5PackId) SBUSY

SCONTOUT

XNOP

SBUSY

SDATAIN

test al,al

je NoASIC5PackOut There

Note that an ASIC4 can pretend to be an ASICS in pack mode and will respond appropriately.

ASIC5 Registers

ASICS has sixteen internal registers. To read or write from an ASICS register takes two steps. First a control byte must be sent along the Psion serial link to select which register. This should be followed by a read or write of the appropriate data value. The sixteen registers are listed in the table below. Some can be read and written to and some are read or write only.

| oO | URW PortAreadandwritedata | 6 | RW Interrupt Maskread and write | 8 | RW __| UART Status/UART Control register | 9 | R/W_| UART Receive/UART transmit holding register_| UART Baud rate LSB

| 13) | OR Barcodereaddata | 4 {| ER Synchronous Port2read

Revision 1.00 Page 56 of 115 pages

The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

Reading from the Port A register causes ASICS to generate a memory access cycle. The value read from port A will be the value retrieved from any attached memory or memory mapped peripheral. Writing to Port A will cause ASICS to generate a write cycle and write the supplied value to attached memory. In both cases the address used for the access will depend on ASICS's mode and the configuration of ports B, C, and D. If the UART is enabled (Bit 0 of the port B mode register) memory cannot be accessed because port A lines are reused.

Writing to port B will cause the value written to be latched onto the output lines PBO-PB7 (which form address lines AO-A7 for memory access cycles). Reading from this register will return the last value written.

Writing to the port B mode controls various aspects of ASIC5 behaviour. The table below indicates the meanings of each bit in the register. When set to operate in counter mode the value output on lines PBO-PB7 can be incremented by reading from the port B mode register, post-incremented by reading or writing to the port A register or cleared to zero by writing to the Port D and C register.

| 0 _| 0, Memory mode. 1, Peripheral mode -enables UART____| | 6 NotUsed a

7 Not Used

POT | Countermode POT Latch mode Pot | Baud rate outon portB

When ASICS is in pack mode the first write to the port D and C register will be latched onto lines PDO-PD7. In multiwrite mode the second and subsequent data writes will be latched onto port C with the following bits in the register forming the following functions.

| Databit_ | Pin, | Function _| a |

The bit SELO and SEL1 determine which chip select is used when a memory access cycle is generated by accessing port A. CSO-CS3 are selected as follows.

CSO

CS2

=

Revision 1.00 Page 57 of 115 pages

The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

In peripheral mode a write to the port D and C register will latch the value written onto lines PD1- PD7. In peripheral mode the line PDO forms the UART TX line. Setting bit zero in the port C and D register therefore has no effect.

ASICS is capable of generating an interrupt due to various external events. The interrupt mask register is used to select which events will generate an interrupt. Writing to the interrupt mask register will set the mask to the value written. Reading the interrupt mask register will return the current mask. The meanings of each bit in this register is given in the table below. Setting an appropriate bit to 1 will enable that events interrupt, clearing to 0 will stop that event from causing an interrupt. On reset all events are disabled.

Bit | OP UART CT UART character received

Synchronous port] character received Synchronous port2 character received | 6 [PCA Barcode data/general interrupt

When an interrupt occurs reading the Interrupt Status register will indicate the source of the interrupt. The meaning of each bit corresponds directly to each bit in the interrupt mask (see table above). A high bit indicates an active interrupt event.

Reading the Barcode data register returns a byte representing the states of the following lines.

Communicating with ASIC4

ASIC4 is capable of operating in several modes. Attached peripherals can contain an ASICS chip instead of an ASIC4. Before talking to an ASIC4 you must first ensure that there is an ASIC4 at the end of your serial link and you must set ASIC4 into the correct operating mode. You must do this when the channel is first obtained to ensure you have the right peripheral to start with, and also whenever you get a Hold and Resume due to a power down, Pack doors opening, or the peripheral being removed. You should also check the peripherals ID to check what peripheral it is. The user is more than likely to pull out your I/O port and replace it with a 3Fax in mid operation. You select ASIC4 in the correct mode by sending a special control code. If there is an ASIC4 out there it will respond by sending back a non zero value. The peripherals ID can be read back from ASIC4's info register. This register also returns the state of the input lines INO, IN1, IN2. The coding example below shows how ASIC4 can be checked for, selected and the peripheral ID checked:

HwNullFrame

mov al, (SerialSelect or Asic4Id) ; First look for an SBUSY ; ASIC4 at the other SCONTOUT ; end of the link XNOP

Revision 1.00 Page 58 of 115 pages

The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

SBUSY SDATAIN test al,al je NoAnASIC4IsItAnASIC5 mov al, (SerialReadSingle or A4InfoR) ; Now see if we SBUSY ; have the right SCONTOUT ; peripheral XNOP SBUSY SDATAIN ; Mask out the unwanted and al,0Of0h ; bits cmp al,PERIPHERAL_ID ; check for correct ID jne IsASIC4ButNotRightPeripheral ; Got our peripheral ele ; Connection Okay! ret IsASIC4ButNotRightPeripheral: + Is an ASIC4 but not popt ; the right peripheral stc ; Connection Failed! ret NoAnASIC4IsItAnASIC5: ; No ASIC4 mov al, (SerialSelect or Asic5NormallId) SBUSY ; Could have been an SCONTOUT ; ASIC5 so try to put XNOP stc ; back in the right mode ret ; Connection Failed

Bits in ASIC4’s info register have the following definitions:

Pot | Dmsb | DT Wiss | TN? TN NO Sending and Receiving data using ASIC4

All ASIC4 peripherals are memory mapped into that ASIC's address space. To access a peripheral or a particular peripheral's register the ASIC must first be told to set its address bus to the appropriate location. Once it has been informed of the address which it is to access that location can be read from or written to as many times as required. The value to be written is held in the data register. To read or write to another location the address that the ASIC is accessing must be changed. To read from a random address within the ASIC's address space the sequence would be:

1) Send a control code to inform the ASIC that it is to set its address bus to the following address.

2) Send the address to position to.

3) Send a control frame to inform the ASIC that we wish to read from this address.

4) Read back the byte.

To write a random value to and address within the ASIC's address space the sequence would be:

1) Send a control code to inform the ASIC that it is to set its address bus to the following address. 2) Send the address to position to.

3) Send a control frame to inform the ASIC that we wish to write to this address.

4) Send the byte.

Overleaf are two 8086 assembler functions Input and Output which read from or write to an address within the ASIC's address space. These functions only give access to the bottom 256 addresses. For peripheral devices this is usually more than adequate. Interrupts should always be off during calls to these functions to prevent the S3/S3a/HC from multitasking. Note that in the following routines, A4Address and A4Data refer to the value of the respective ASIC4 registers. SerialWriteSingle has the value corresponding to a single frame write in the SIBO serial protocol format. These system defines can be found in the important include files ospack.inc and ossibo.inc.

ProcBegin@ Output

; ;

; Output byte to ASIC4-based peripheral

; IN: DL holds the hardware address ASIC4 is to write to

Revision 1.00 Page 59 of 115 pages

The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

; AL holds the byte to be output to that address

push ax

mov al, (SerialWriteSingle or A4Address) ;CTRL=Write to A4 address reg

SBUSY

SCONTOUT ;Send this control frame

mov al,dl ;DATA=Hardware address

SBUSY

SDATAOUT ;Send this data frame

mov al, (SerialWriteSingle or A4Data) ;CTRL=Writing data now

SBUSY

SCONTOUT ;Send this control frame

pop ax ;DATA=Data to write

SBUSY

SDATAOUT ;Send this data frame

ret

ProcEnd noret

ProcBegin@ Input

; Input byte from ASIC4-based peripheral 7 IN: DL holds the hardware address ASIC4 is to read from ; OUT:AL holds the value read from that address

mov al, (SerialWriteSingle or A4Address) ;CTRL=Write to A4 address reg

SBUSY

SCONTOUT ;Send this control frame

mov al,dl ;DATA=Hardware address

SBUSY

SDATAOUT ;Send this data frame

mov al, (SerialReadSingle or A4Data) ;CTRL=Reading data now

SBUSY

SCONTOUT ;Send above control frame

SBUSY

XNOP

SDATAIN ;Receive data frame

ret ;AL holds the data

ProcEnd noret

Obtaining and using a channel

The s3/S3a/HC have three Psion serial links. Only one of these channels can be selected for communication at any one time. Two of these channels form the SSD slots. The third forms the expansion port. Before a device driver is able to talk to a peripheral it must both own and have this third channel selected. Many device drivers can exist in memory and more than one may access the peripheral. To prevent multiple access to a single peripheral a device driver must first own a serial channel before it is free to communicate to the ASIC4/S peripheral at the end of it. To check if a channel is free and then reserve it call the operating system function HwGetChannel. This will return with carry clear if the attempt to capture the channel was successful, carry set otherwise.

mov al, InterruptMaskForDesiredChannel HwGetChannel jc CouldntGetTheChannel

Obtaining the desired channel will usually be performed by a device drivers open vector. Open should fail if the channel is unavailable. If a device drivers takes possession of a channel it is its duty

Revision 1.00 Page 60 of 115 pages

The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

to free it again once it is finished. This would normally be done when the device drivers is closed and is performed by the operating system function HwFreeChannel.

mov al, InterruptMaskForDesiredChannel HwF reeChannel

As illustrated in the above table, on a series 3a the interrupt mask for the expansion port (Port C) is defined by A9MSlave, on a series 3 Asic2Int. Interrupts are IRQ2 and IRQ4 respectively. Only one serial link can ever be selected at one moment in time. Selecting a particular channel means that you are unable to speak to another without selecting it instead. To select a channel the operating system call HwSelectChannel is used.

mov al, SelectForDesiredChannel HwSelectChannel push ax

HwSelectChannel will return in al the channel that was previously selected. Device drivers should select the correct channel on entry to any vector or interrupt service routine that needs to communicate down that channel. On exit the previously selected channel should be restored. Between the time when the channel is first selected and when the old channel is restored multitasking should be disabled. this will usually mean switching off interrupts. Because of the watchdog timer, interrupts cannot be left off for an indeterminate length of time. Communications down channels therefore will usually be restricted to short bursts. For the expansion port the channel to select on an S3a is defined by Select Channel5 on an $3 SelectChannel7.

pushf

eli

mov al, SelectChannel5 hwSelectChannel

push ax

mov dl, AddressOfInputBuffer call Input

mov dl, AddressOfOutputBuffer

call Output

pop ax hwSelectChannel popf

Controlling ASIC5's UART

Before data can be sent or received from ASIC5's UART continuous clocking from the host must be enabled and a baud rate selected. The UART must be enabled by setting bit 0 in the port B mode register. The selected baud rate value is related to the result of dividing the required baud rate into the input clock frequency from the host of 1.536 MHz. The value generated from the equation given below forms a sixteen bit word. ASICS has two registers for selecting the baud rate. Register 10 should contain the least significant byte and register 11 the most significant byte of the calculated word value. The table below lists the divisor values for some of the more commonly required baud rates:

Divisor = 1-(96000/Desired Baud Rate)

9600 a ee ae ee 7200 fff 4800

Revision 1.00 Page 61 of 115 pages

The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

The format of data communicated, stop bits, data bits, parity checking, is controlled by writing to the UART status/control Register. Bits in the UART status/control register have the following meanings:

| 0 | Stateof the CTS line (PAI) ___| Generate break character iar

A character to be transmitted should be written to the Transmitter Holding Register where ASICS will convert it to serial form for transmission. The register will be emptied once the character has been transmitted. ASIC5 contains no internal buffering. The Transmitter Holding Register must be empty before writing a character to it. The state of the Transmitter Holding Register is reflected in the Transmitter Empty bit in the UART status register. Enabling the Transmitting Holding Register interrupt will cause ASICS to generate an interrupt every time that the Transmitting Holding Register becomes empty. Reading the UART Status Register will clear the interrupt. Received characters are copied into the Receive Character Register. If the Receive Character Interrupt is enabled ASICS generates an interrupt on each character received. If the character is received in error due either parity, framing or overrun errors, appropriate bits in the UART Status Register are set to reflect this.

Hold and Resumes

There are three types of hold and resume. The first occurs when memory is being moved. An LDDs hold and resume vectors will always be called when this occurs. The second is a On/Off Hold and resume. An LDD will always be held and resumed when this occurs although it is not guaranteed that power will have been restored to the expansion ports when the resume is issued. The third type occurs when one of the pack doors is opened or a peripheral inserted. Only certain internal LDDs receive a Hold and Resume under these circumstances. Any loaded LDD will definitely not receive a Hold or Resume. To get around these problem, the TcK: device driver is used to provide a regular call to a routine within your driver. This call monitors the power to the expansion port and issues its own holds and resumes as appropriate. Holds and resumes can become nested and the whole situation can become rather complicated. The correct procedure for dealing with holds and resumes for an ASIC4 peripheral device driver (LDD) is given below.

When a hold is received through the normal route the channel is marked as being under a normal hold. If the polling routine sees that the power has vanished and the channel is not already under a

Revision 1.00 Page 62 of 115 pages

The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

normal hold then it holds the channel and marks it as being under a special hold. If a normal resume is issued channel can be resumed but only if power is present. If power is not present then the channel is marked as being under a special hold and the resume is put off. If the polling routine sees that the power is present and that the channel is under a special hold then it should resume the channel.

Alternatively of course each time you read and write to your peripheral you could do a quick pre- check to see if the hardware is available and set-up correctly. This would dispense with the need to handle power up/down or pack door holds and resumes. You would still have to start and stop interrupts though when appropriate.

Example Device Drivers

An example device driver which will control the ASIC4 Example Interface Board described earlier can be found in the file A4EXIF.ASM. The device driver is a fully comprehensive multi-channel implementation. It supports all the mandatory logical device driver functions. Open will fail if the Interface Board hardware is not present. It has an interrupt service routine and handles Holds and Resumes correctly in all the distinct cases outlined earlier. In addition, asynchronous reads of the LED status are possible so a special routine to handle this case, the Wait Handler, is included. The driver has been made as fully comprehensive as possible both in terms of functionality and the choice of host machine. To this end, the code given can be compiled for the entire range of Psion machines simply by changing the appropriate machine Build Flag at the head of the file which then causes the correct interrupt masks to be selected for the machine. Chapter 11 of this document details the structure of A4EXIF.LDD a logical device driver constructed for the ASIC4 Example Interface Board.

Chapter 12 details the functionality of a physical device driver for the ASIC5-based Psion 3-link peripheral that enables the host hardware to communicate with a PC by converting SIBO serial protocol signals into RS232 signals. Once again, this driver contains various build flags to facilitate conditional compilation. Common interrupt routine code is included and the LDD-PDD interface is specified.

The source code for both A4ZEXIF.LDD and SYS$AS5.PDD is presented in the appendix to this document.

Revision 1.00 Page 63 of 115 pages

The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

11. AN EXAMPLE DEVICE DRIVER FOR ASIC4: A4EXIF.LDD

Introduction

In this chapter, the functionality and code structure an example installable logical device driver, A4EXIF.LDD, is presented in some depth. Circuit details of the corresponding Psion peripheral for this driver, the ASIC4 Example Interface board, were outlined in chapter 8. A4EXIF.LDD enables software written using the Psion SDK to communicate with the prototype ASIC4 Example Interface board through means of standard PLIB calls such as ‘p_open' and 'p_write’. The description of A4EXIF.LDD is intended to provide a clear insight into the generalised structure of logical device drivers for peripherals based around the SIBO architecture. To this end the actual usefulness of the combined hardware-driver interface is of secondary importance. As shown earlier, the ASIC4 Interface Board translates SIBO serial protocol signals into a parallel 8-way data bus format which can be used to set various 74HC series latches and gates. An eight-bit buffer and latch are commoned to eight LEDs. The latch is write-only and is used for setting the state of the LEDs. The buffer is read-only and is used to sense the state of the LEDs. In addition, a facility for generating hardware interrupts is provided by means of a suitably connected switch and third 8-way buffer (the status buffer). Address decoding is provided by two 2-to-4 decoders attached to address lines AO and Al.

Code Structure

Loading A4EXIF.LDD and Device Names

A4EXIF.LDD is loaded into the RAM of the host machine by means of the following PLIB call in the application code:

p_loadldd ("A4EXIF.LDD") ;

The name of a device driver is the mechanism by which an application can obtain a channel to that device driver. LDDs all have three character names which are stored in the second field of the driver's LibEnt structure followed by a colon. This name is required to uniquely identify the LDD to the OS when attempting to open a channel on it. The A4EXIF LDD has the three character name "LED" so a channel with its handle in pcb may be obtained on it by means of the following call:

p_open (&pcb, "LED:",-1);

EPOC used the driver name in the p_open call to invoke the ToOpen system service which in turn invokes the Open vector on the associated device driver.

The Single Code Segment and Data Storage

As indicated earlier, loadable Psion device drivers have a single code segment and no data segment. Data associated with the driver is stored in one of two distinct ways dependent on its nature. Global data associated with the driver is stored in its code segment. Examples of such data are the channel interrupt masks and numbers have to be visible to all processes that may be using A4EXIF.LDD. Data local to the application invoking the driver, however, is stored in the heap space of that application. An example in A4EXIF.LDD would be the pointers to the open channel strategy vector parameters.

The overall structure of the code segment is typical of Psion logical device drivers. The code segment begins with a CodeSeg directive followed by the LibEnt structure which defines the mandatory device driver functions as well as two non-mandatory ones. These are the Wait Handler and the replacement

Revision 1.00 Page 64 of 115 pages

The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

Tick Interrupt Vector. Before entering the code for these functions, all global variables are declared in what is termed the device driver's internal data space. Following the code for the Lib Ent functions comes the code for all the local driver functions. After these are the EndCodeSeg and end A4ExifLDD directives.

Channel Status Ent and Open Channel Control Block

At the head of the driver's assembler source file A4EXIF.ASM, various constants, compiler defines and type definitions are listed. It is here that templates are declared for the global structures that hold the key driver variables. In view of the above discussion, most device drivers employ at least one globally defined structure to hold the various important flags and masks that relate to the status of each separate channel on that driver. In the case of A4EXIF.LDD, two different structure types are employed, namely A4ExifStatusEnt and A4ExifEnt. The former is referred to in this chapter as the StatusEnt struc and is instantiated later on in the device driver code segment with each separate permissible channel of the main Psion host machines being assigned its own StatusEnt struc. A channel's StatusEnt struc is generally accessed through CS:DI and holds important channel-related information such as the A4ExifChannelOpen and A4ExifChannelRunning flags and the channel interrupt masks and interrupt numbers. The StatusEnt structure resides in the driver code segment whereas the A4ExifEnt struc is held in the heap space of the application invoking the driver and so is accessed through DS:BX. The A4ExifEnt structure contains a number of variables that are logically associated with a successfully opened channel and as such should be distinguished from the StatusEnt variables. An A4ExifEnt struc instantiated by invoking the device driver's open vector is referred to as the open channel control block and it is generally accessed through DS:BX.

The layout of both the StatusEnt struc and the A4ExifEnt open channel control block struc are presented later in this chapter along with various other important pre-defined structs that were used in the construction of A4EXIF.LDD. Both of these structures were extensively used in the coding of the LDD functions described in the following pages.

SIBO hardware and conditional compilation

The number of expansion channels supported by a host SIBO machine is dependent on the hardware. In the case of the S3a, only one SIBO channel can legitimately be opened corresponding to expansion port A. With the HC and Workabout, it is possible to open up to three separate SIBO channels on ports A through to C. In A4EXIF.LDD, a global constant numberofchannels 1s set at the start of the device driver code segment to indicate the number of serial SIBO channels supported by the different machines. This will vary according to the Psion hardware present and in order to aid conditional compilation of the A4EXIF driver for the different host machine possibilities, a number of build flags can be used to set various constants within the include files. The hardware options with regard to these flags were outlined in the previous chapter.

It should be noted that Psion device drivers should be designed to be easily adapted from machine to machine. With the A4EXIF driver, for instance, the only change that needs to be made in adapting it for use on another Psion machine is the alteration of the build flag at the start of the code segment. This flag indicates to the compiler which SIBO machine flags as well as other variables should be set. The SIBO machine flags are in turn used later in the code segment header to set the global numberofchannels variable mentioned above. For example, in A4EXIF.LDD, we have the following:

if Corporate or Workabout numberofchannels equ 3 else

endif

This type of code is used extensively in the conditional instantiation of A4ExifStatusEnts in the device driver's internal data space. Here different interrupt masks and SIBO channels are invoked for the different machines according to the host controller ASIC. For instance, in the case of a consumer (S3a), the hardware interrupt mask corresponding to expansion port C on an ASIC9 is mask A9MsSlave and the interrupt number is HwIrq2Revector. On an Workabout, the masks for expansion

Revision 1.00 Page 65 of 115 pages

The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

ports A, B and C are A9MExpIntA, A9MExpIntB and A9MSlave respectively. The corresponding interrupt numbers are HwIrq4Revector, HwIrq5Revector and HwIrq2Revector. This conditional compilation code in A4EXIF.LDD outlined here is worthy of some study because it encapsulates all the information regarding masks and SIBO hardware channels required by the prospective developer interested in constructing a multi-platform Psion peripheral and driver.

Mandatory LDD Functions

The eight mandatory LDD functions are the Install, Remove, Hold, Resume, Reset, Units, Open and Strategy and they are all discussed in the context of the example device driver A4EXIF.LDD below.

A4Exifinstall IN: No values are passed to the install vector. OUT: If successful return with carry clear. If installation unsuccessful, return with the carry flag set and error number in the AL register.

PRESERVE: SS, SP and BP

The install vector is called by the operating system when the device driver is loaded in order to initialise any internal variables. It should not be called directly by an application process but invoked indirectly by a 'p_loadldd("A4EXIF.LDD")' call. Typically at this stage the various open channel flags would be initialised to zero but in the case of the A4EXIF.LDD, this has already been done in the appropriate A4ExifStatusEnt struc headers. As a result, the install vector merely clears the carry flag and returns.

A4ExifRemove IN: No values are passed to the remove vector OUT: If successful return with carry clear.

If installation unsuccessful, return with carry set and error number in the AL register. PRESERVE: SS, SP and BP

The remove vector is called by the operating system whenever the device driver is requested to be unloaded which is usually indirectly as the result of a call to 'p_devdel ("LED", E_LDD)'. ROM- resident drivers cannot be deleted so any attempt to invoke this vector on them will result in an error being returned. The code for the remove vector checks to see that all the device driver channels are closed and returns carry clear if this is the case. In the case of A4EXIF.LDD, a closed channel will hold a zero in its corresponding StatusEnt open channel flag. If any of the open channel flags is non- zero then the carry flag is set before returning indicating that an attempt has been made to unload a device driver that still holds at least one open channel. In the case of A4EXIF.LDD, the numberofchannels flag is used as a loop counter for the different hardware channel possibilities in a similar manner to the corresponding code in the open vector.

A4ExifHold

IN: AH register holds one of the following values: DevHoldNormal, DevHoldPowerDown Or DevHoldPowerFail

OUT: None

PRESERVE: SS, SP and BP

The hold vector is called by the operating system whenever the device driver is requested to be held. This can occur as a result of three conditions which result in the three different possibilities for the value held in AH:

1. Device memory segments about to be moved. AH holds DevHoldNormal.

Revision 1.00 Page 66 of 115 pages

The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

2. Machine about to switch off due to power-save time-out or the off switch being pressed. AH holds DevHoldPowerDown.

3. Machine about to switch off due to power source being removed or the batteries failing. AH holds DevHoldPowerFail.

The hold vector code must be able to conduct a rapid shut down of the device driver because in the case of DevHoldPowerFail, the driver may only have a couple of ms before internal voltages fall to an unworkable level. The EPOC OS automatically handles the three cases highlighted above but in Series 3a machines and the Workabout, in addition to these there is another situation that requires the invocation of the hold vector, namely the opening/closing of the SSD pack doors on an S3a or Workabout. This is an action which can only be detected by means of software polling which requires the setting up of the ROM-resident "TcK:" device driver so that the door status can be checked each system tick (i.e. 32 times a second). The section on A4ExifTickInt provides a more detailed outline of the TCK interrupt code required to handle pack door opening and closing. It is this latter routine that polls for the open or closed status of the host machine doors, setting the global HoldFlag accordingly. The Hold vector code thus includes a check on the status of the HoldFlag and is generally optimised to be as efficient as possible. An outline of the structure of A4ExifHold presented below. It follows the pattern for a typical device driver:

e Check the state of the global HoldFlag.

e If the flag is non-zero, then the driver is already held and the function returns without taking any further action.

e = If the HoldFlag is zero, then the function checks the status of all the channels that the driver is permitted to open. If any of these channels have their open channel flags cleared, it is not necessary to do anything as part of the process of holding the channel. Only in the case when the flags are set is the 'stopChannelRunning’ function invoked. As with the similar loop in the Reset vector, the global numberofchannels is used as the loop counter as each of the possible channels has to be checked.

A4ExifResume IN: None OUT: None

PRESERVE: SS, SP and BP

The resume vector is called by the operating system to restart a held device driver. Resume will be called after a hold caused by any of the four possibilities indicated above in the section on A4ExifHold but it should be noted that in some cases, ASIC4 will only be switched on after the call to resume. The device driver is expected to recover from the previous hold and resume any suspended I/O except in the case of power failure where the resume vector ought to power up the peripheral and put it into a known state indicating to the user that data may have been lost. The resume vector will also have to handle the reinstallation of any interrupt service routines by checking the status of the open channel flag.

e Check the state of the global HoldFlag.

e If the flag is zero, then the driver has already resumed so return without further action.

e If the flag is non-zero, then check the door status of the host machine with a call to the OS HwGetSsdData service. If the doors are open, then set HoldFlag to 2 to signal this position to the driver. If the doors are closed, then numberofchannels is used as a loop counter while the open channel flags of each of the permissible channels for the host hardware are checked. Only if these flags are set is the 'start TheChannelRunning’ function invoked.

A4ExifReset IN: BX holds the device driver device handle CX holds user specified channel identification data. In this case, holds the address of the status struc identifying the open channel to be reset. OUT: None

Revision 1.00 Page 67 of 115 pages

The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

PRESERVE: SS, SP and BP

The reset vector enables a device driver to reset itself when the application which owns the device driver terminates abnormally before closing one or more open channels on that driver. The vector is only invoked by the operating system if it has been primed by means of a call to the ToRequestReset operating system service in the open vector. Such a call must be balanced by a corresponding call to IoRequestResetCancel in the close function code of the strategy vector. Registers BX and CX are required to be set up by the user prior to invocation of either of these services. BX should contain the device driver handle which is passed through DX in the open vector. CX should hold any suitable open channel identification data that can be accessed in the driver's internal data space (i.e. through CS:DI). In the case of A4EXIF.LDD, this information is the address of the channel StatusEnt structure. If a device driver is only capable of opening one channel, then it is irrelevant what CX holds. A reset should only be outstanding while some process has a channel open on the device driver. The format of A4ExifReset is similar to that of a typical reset vector and can be summarised as follows:

e Move the address of the channel status Ent from CX into DI.

e Check the value of the corresponding cs:[di].A4ExifChannelOpen flag.

e If channel is not open to reset, then return from the vector otherwise call "StopTheChannelRunning’ and use HwFreeChannel to release the SIBO serial channel. Set the ChannelOpen flag to zero.

A4ExifUnits IN: None OUT: AX holds the number of channels supported.

PRESERVE: SS, SP and BP

The A4ExifUnits function is called by the operating system when the device driver is requested to report the number of units (or channels) that it can support. This is primarily useful for purposes of information.

A4ExifOpen

IN: DX contains the device handle of the device driver SL is a pointer to an OpenEnt struc BP is a pointer to an IntEnt struc DS, ES point to the application process's data segment OUT: If successful return with carry clear and the address of the open channel in BX. i.e. BX holds the address of an A4ExifEnt struc which contains various fields of information concerning the open channel. If installation unsuccessful, return with carry set and error number in the AL register. PRESERVE: DS, ES, SS, SP, BP and DX

The open vector is called by the operating system when a channel to the device driver is required to be opened. The device handle, which is passed through DX, is used by the operating system to route any I/O requests on the opened channel to the correct device driver. An LDD must place this handle in the ChanLibHandle field of the ChanEnt struc of the open channel structure allocated within the application's data segment. In the case of A4EXIF.LDD, this structure is the A4ExifEnt struc described in the Appendix to this document. The open vector of a device driver runs in the context of the process that has called p_open to open a serial port on that device driver.

The OpenEnt struc consists of three fields , OpenNamePtr, OpenMode and OpenChan. The OpenNamefPtr points to the character immediately following the device name as passed in the p_open call. For instance, in the case of A4EXIF.LDD, the OpenNamePtr would point to the colon after LED in the name "LED:". The OpenMode field contains the mode for opening the device driver

Revision 1.00 Page 68 of 115 pages

The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

which is not used in this example. The OpenChan field holds the I/O channel handle of the device that the driver is required to 'attach' to. Attached drivers add functionality to, or replace, a service provided by an underlying device driver. The IntEnt struc pointed to by BP can be used to reload the various segment registers if their contents have been altered. The A4ExifEnt struc requires further elaboration. It consists of four fields: A4Exiflo, A4ExifHandlerPtr, A4ExifStatusPtr and A4ExifA1Ptr. A4ExifHandlerPtr contains a handle to the driver's WaitHandler, A4ExifHandler. This is the routine required to handle the completion of asynchronous I/O requests and is described in more detail later on in this chapter. Of the remaining fields, A4ExifStatusPtr holds the location of the completion status word for I/O requests and A4ExifA1Ptr is a user-defined parameter. These two values are passed to the strategy vector through the RqEnt structure. A4Exiflo is itself a ChanEnt struc with sub fields ChanSignature, ChanNext and ChanLibHandle. After initialisation of this structure, [bx]. A4Exiflo.ChanSignature must hold 'TochanSignature’ and [bx].A4Exiflo.ChanLibHandle holds the handle to the device driver (stored in DX). Both of these values are again required by the strategy vector. The [bx].A4Exiflo.ChanNext field is used by attached drivers and is set to 0 for root drivers like A4EXIF.LDD.

The code in an open vector follows a similar pattern in many LDDs and is presented in outline form below:

e Determine the channel to be opened using the pointer to the device name held in [si]. OpenNamePtr.

e If OK, disable interrupts and invoke the OS HwGet Channel call.

e If OK, then set A4ExifChannelOpen flag to non-zero.

e In order to poll for door-opening and closing, it is necessary to open a "TcK:" channel at this stage and initialise it by means of using the OS IowithWait service to call the TickInt vector on each system tick.

e Re-enable interrupts and set up the calling process id using the ProcId service.

e Check for the presence of the required hardware. If present return with carry clear.

e Allocate space in calling process' heap (i.e. the application data space) to contain the I/O channel control block (an A4ExifEnt struc in the case of A4AEXIF.LDD) and set its base address to BX (thus BX holds the address of the open channel control block).

e If OK, install the device driver Wait Handler using the IoAddHandler system service. A Wait Handler is required only if there are any asynchronous I/O requests to be handled.

e If OK, initialise the fields inside the I/O channel control block that were outlined above.

e Invoke IoRequestReset system service to handle unexpected termination of main program by invoking the driver's Reset vector.

e Before leaving the Open vector, if the call succeeded, BX must hold the open channel control

block handle. A4ExifStrategy IN: BX holds the allocated channel control block initialised in the open vector

DX contains device handle of the device driver in the case of an LDD

SL is pointer to RqEnt struc

BP is pointer to IntEnt struc

DS, ES point to data segment of application making the I/O function request

OUT: If successful return with carry clear. Furthermore, in this case, if the strategy vector is meant to complete the I/O request (as is the case with IoClose for instance) then the completion status should be written back to RqStatusPtr location and the I/O semaphore signalled by calling IoSignal. If the I/O request is not completed by the strategy vector (as is the case with the asynchronous functions IoFuncRead and IoFuncWrite) then PendingErr should be written back to the location pointed to by

RqStatusPtr and the I/O semaphore should not be signalled.

If installation unsuccessful, return with carry set and error number in the AL register. PRESERVE: DS, ES, SS, SP and BP

Revision 1.00 Page 69 of 115 pages

The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

When an application makes a I/O request on the opened device driver channel, the request is routed to this vector by the operating system. A device driver defines the set of strategy functions that it supports such as IoFuncSet, IoFuncSense, IoFuncWrite and IoFuncClose. The functions of a device driver are usually dependent on its purpose and there is no requirement to support any particular function. The ordering of these functions in the strategy vector table is defined in p_file.h and presented in A4EXIF.ASM.

The SI register contains a pointer to an RqEnt struc which consists of four fields: RqFunction, RqStatusPtr, RgA1Ptr and RqA2Ptr. RqFunction contains the function number passed to the I/O request by the application. In the device driver strategy vector code, the value held in RqFunction is compared against the supported function numbers held in ToFuncClose, IoFuncRead etc. If the function number is not one of those supported then a call to IoRoot is necessary in the case of a root device driver such as A4EXIF.LDD. toRoot chains the I/O request through to the operating system which runs some default code to handle it. RqStatusPtr is a pointer to a memory location in the application data space which holds the value of the I/O request's completion status word. While a request is outstanding, this value is set to PendingErr and only when it completes does a completion code get written to this location. I/O requests can complete within the strategy vector or later after an interrupt. Often as is the case with A4EXIF.LDD, only a single request of any one kind can be outstanding at any time otherwise the application is panicked. RqA1Ptr and RqA2Ptr hold the values of two parameters that are passed to the IoAsynchronous EPOC service. Each synchronous strategy function has a similar pattern with explicit I/O being conducted whilst interrupts are disabled and a completed request being signalled with an OS ToSignal call prior to exit from the function. This call signals to the OS the completion of the particular I/O request entailed by the function call. The situation with regard to the one asynchronous strategy function is somewhat more complicated and is dealt with in greater detail in a later section.

The structure of the strategy vector of A4EXIF.ASM is outlined below:

e Determine the strategy function number using [si].RqFunction and compare with the below:

e JIOFUNCREAD: Asynchronous read of latches U4 and U3. Panic if [bx].A4ExifStatusPtr != 0. Update [bx].A4ExifA1Ptr and [bx].A4ExifStatusPtr with [si].RqA1Ptr and [si].RqStatusPtr respectively as the locations to be accessed on receipt of interrupt. Move PendingErr into the location pointed to by [bx].A4ExifStatusPtr to signal that the request is awaiting completion. Allow handler to be enabled through the IoEnableHandler OS call and exit without signalling completion of the request.

e IOFUNCWRITE: Identical behaviour to that of IoFUNCSET which it calls.

e TIOFUNCCANCEL: Used to cancel any pending asynchronous reads. This involves disabling the wait handler, consuming any stray signal from the interrupt routine by means of an OS IoWaitForSignal call and then storing cancelErr in the channel I/O request status word.

e IOFUNCCLOSE: Close down the TCK channel and remove handler. Disable interrupts and HwFreeChannel setting A4ExifPid to 0 before re-enabling interrupts. Invoke IoRequestResetCancel system service and HeapFreeCell. Signal completion of I/O request by calling IoSignal system service.

e IOFUNCSENSE: Reads the status and LED bytes from latches U4 and U3 respectively storing the results at the addresses pointed to by RgA1Ptr and RqA2Ptr.

e IOFUNCSET: Sets latch U5 to contain the value pointed to by the sole argument in the call to P_FSENSE.

e If not supported then call IoRoot system service.

The Non-Mandatory LDD Functions

The eight functions described above must be supported by all device driver. Typical Psion LDDs employ at least two other LDD functions. The first of these is a pseudo-interrupt routine which is invoked by the OS on each system tick. In A4EXIF.LDD, this function is represented by A4ExifTickInt and an outline of its purpose was presented earlier in the discussion on holding and

Revision 1.00 Page 70 of 115 pages

The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

resuming device drivers. As was indicated then, the minimum functionality required by this routine is to poll the status of the host machine doors and if appropriate call the driver's Hold and Resume vectors. If in addition the LDD is intended to service any asynchronous I/O requests, a wait handler and common interrupt service routine are required. With A4EXIF.LDD, these two additional functions are represented by A4ExifHandler and ComInt respectively. The former function constitutes the second of the additional LDD functions as can be seen by examining the LibEnt structure for A4EXIF.LDD. The latter function is set up so that it replaces the default interrupt service routine code invoked by the OS on the receipt of hardware interrupts on the peripheral's SIBO channels. A4ExifHandler is invoked by the OS every time the I/O semaphore of the process that opened the channel is signalled with through an IoSignalByPidNoResched call indicating that an interrupt has been received and an outstanding I/O request has completed. The function of the wait handler is to deal with I/O semaphore signalling and to update the appropriate open channel control block field variables. The common interrupt service routine code in ComInt cannot do this because it is not permitted to access the application data space. This in turn is because the routine runs in the context of the process which was running when the interrupt occurred. A4ExifTickInt, the wait handler and the common interrupt service routine for A4EXIF.LDD as well further details as to how the latter two interact to handle asynchronous I/O requests are described below.

A4ExifTicklint

As was explained earlier in discussing the A4ExifHold vector, it is necessary to utilise the "TcK:" system tick device driver in order to handle the particular case of invoking a hold on A4EXIF.LDD when the host machine SSD pack doors are opened. Such an action automatically causes power to be removed from any peripherals. The TCK driver is opened via an OS Toopen call in the A4ExifOpen vector which returns with carry clear and a non-zero handle in AX if successful. In this case, the IoWithWait function is called to request an synchronous I/O service from the TCK driver. Prior to this call, the service number requested is held in AL and the I/O handle procured from the previous call to ToOpen is loaded into BX. The interrupt number of the tick poll routine, A4ExifTickInt, is loaded into CX so that as its parent driver is invoked on each system tick, the OS enters this vector. The reason the TickInt routine is required in A4EXIF.LDD is solely to handle the problem of recognising a sudden removal of power from the host machine. The OS has no way of testing for this condition other than polling its global 'Doorstatus' variable every system tick and taking the requisite course of action. As such, the outline of the code for the tick poll routine which is required in all Psion LDDs can be presented below. This outline should be carefully compared with the structure of the Hold and Resume vectors shown earlier in order to see how they interact:

e Check the current status of doors which is held in SI. If DoorlsOpen then if global HoldFlag is zero, force a call to A4ExifHold, set HoldFlag to 2 and return far else do a far ret e = Else if DoorIsClosed then if global HoldFlag is 2, force a call to A4ExifResume and return far else do a far ret

It should be emphasised that A4ExifTickInt is only a pseudo interrupt service routine in that it does not preserve the status of the registers which is something that the device driver writer must undertake to ensure is done explicitly.

The handling of synchronous and asynchronous I/O

The provision of synchronous and asynchronous I/O services are an important aspect of writing any device driver. In the case of Psion drivers, all such services are the provided through the Strategy vector which is typically preceded by a Strategy Vector Table listing the complete set of I/O services that can be invoked on the driver. The strategy vector table for A4EXIF.LDD is presented below to provide an indication as to the kind of service routines that can be written:

StrategyVectorTable label word

Revision 1.00 Page 71 of 115 pages

The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

dw offset A4ExifDefault 7StrategyPanic

dw offset A4ExifRead ;StrategyRead (function define is P_FREAD)

dw offset A4ExifWrite ;StrategyWrite (function define is P_FWRITE) dw offset A4ExifClose ;StrategyClose (function define is P_FCLOSE) dw offset A4ExifCancel ;StrategyCancel (function define is P_FCANCEL)

dw offset A4ExifDefault 7StrategyAttach

dw offset A4ExifDefault 7 StrategyDetach

dw offset A4ExifSet ;StrategySet (function define is P_FSET)

dw offset A4ExifSense ;StrategySense (function define is P_FSENSE)

Both synchronous and asynchronous I/O requests can be made on the driver through means of the PLIB 'p_iow (pcb, <func>, &A1, &A2)' call where pcb is the open channel handle, <func> is one of the above function defines and Al and A2 are two optional parameters required for the servicing of the request. The routing of an I/O request to the correct service code is done by the common code at the head of the strategy vector. Each time this vector is entered, BX holds the address of the open channel control block, DX the device handle of the device driver and SI a pointer to the strategy RqEnt struc used by the OS to follow the course of the I/O request. Using this information, it is possible to access all the relevant flags in the channel StatusEnt by moving [bx].A4ExifStatusEntPtr into DI. This leaves us with the open channel control block in DS:BX and the channel StatusEnt in CS:DI.

Armed with the above information, it is possible to outline the general pattern of both synchronous and asynchronous I/O requests at an OS level. The case of synchronous requests is particularly straightforward since the servicing of the request can be completed entirely within the relevant strategy vector table function. It should be emphasised that in the outline presented below, disabling and re-enabling of interrupts only actually has to be done around any I/O.

SYNCHRONOUS I/O REQUEST STRATEGY VECTOR TABLE FUNCTION

pushf cli ;Disable interrupts < request service code > ;Relevant synchr. I/O processing

ExitWithCompletionStatusZero: < set I/O request status word to zero >

IoSignal ;Signals completion of I/O to OS XOr ax, ax

onl ol ;Tells OS that strategy exited OK popf ;Re-enable interrupts

ret

ProcEnd noret

Note that in the above outline, the single ToSignal call is made after completion of the I/O request in order to signal this fact to the OS. The situation is somewhat more complicated in the case of an asynchronous request because the I/O request strategy vector table function has to interact with both a wait handler function and an interrupt service routine. Of the I/O request services outlined above for A4EXIF.LDD, only one, namely A4ExifRead, is asynchronous and it serves as a good illustration of the nature of programming for asynchroneity. The steps taken in the A4ExifRead vector are outlined below:

e = Set the ChannelReadCompleted flag to 0 (stored in cs:[di]. A4ExifChanReadCompleted) e If the address of the I/O request status word is non-zero then panic (i.e. there is an outstanding read request)

e Update the open channel control block variables using the RqEnt struc

e Load I/O request status word with PendingErr

e Enable the wait handler by using the To—EnableHandler OS service The read request is now in a pending state waiting for completion via receipt of a hardware interrupt. When such an interrupt is received, the OS switches into the appropriately configured common interrupt routine ComInt. Here, the channelReadCompleted flag is set to indicate to the handler that the read request has completed. An IoSignalByPidNoReSched OS service call is also made to indicate to the OS that an as yet unspecified I/O request has terminated. This signal is consumed by the OS which means that at this stage, an IoSignal for completion of the original asynchronous request has yet to be made. The interrupt service routine exits after sensing the status and LED byte values from the ASIC4 Example Interface Board and loading the appropriate response bytes into the relevant locations in the device driver code segment. More details as to the functionality of the interrupt service routine are provided in the section on interrupts. The OS now invokes all the currently active wait handlers in order to determine which application is responsible for consuming

Revision 1.00 Page 72 of 115 pages

The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

the completed read. The wait handler code includes the all-important IoSignal call that indicates to the OS that the original asynchronous read request has finally been accounted for. Receipt of this signal by the OS constitutes completion of the request. The outline code for the A4EXIF.LDD wait handler A4ExifHandler is outlined in the next section.

A4ExifHandler

A WaitHandler is a special function of the LDD which is nominated to be called by the operating system every time the I/O semaphore of the process that opened the channel is signalled. It will only actually be called if the application is already waiting for an outstanding I/O request to complete (1.e. while the application is hung in p_iowait). The handler function is the means by which hardware interrupts can be filtered through to the process which opened the I/O channel since it permits the rescheduling of processes.

The WaitHandler is invoked in the open vector by using the IoAddHandler system service. When an application makes an I/O request, the I/O semaphore is signalled and the operating system calls the Wait Handler function while the application is waiting for the request to complete. The wait handler returns with CLC if no outstanding request has completed. Otherwise the wait handler returns with STC and zero in AL. The wait handler can include within it synchronous I/O requests to cancel or use up signals but it is not entered recursively (i.e. re-enterently) by the operating system. A wait handler is best viewed as a necessary requirement in dealing with the I/O semaphore signalling which cannot entirely be addressed in the appropriate interrupt service routine because the latter is not able to access the open channel's control block.

Interrupts and Interrupt Service Routines

The SIBO architecture allows for eight separate hardware interrupt sources. The EPOC operating system provides a GenSetRevector service to enable a device driver to install an interrupt service routine for any of these eight interrupt sources. When an interrupt occurs, the operating system preserves the state of all the registers before calling the appropriately-installed interrupt service routine. As a result of this, the interrupt service routine is free to employ any register it sees fit to use. A few important points ought to be made concerning the code within an interrupt service routine:

e On an 8086 processor, interrupts cannot be nested so their is no requirement to disable interrupts whilst inside the interrupt service routine.

e Interrupt service routines should operate as fast as possible. In general, operating system service routines are tuned to be of less than Ims duration.

e Interrupt service routines run in the context of the process that was running at the time of the interrupt and should access only the device driver data space which, as with A4EXIF.LDD, typically resides in its own CS space.

e Interrupt service routines should not cause a process rescheduling. To indicate that an event has occurred to the interrupted process, the ToSignalByPidNoResched system service should be called. If a call is made to this service, the interrupt service routine should exit with CLC otherwise it returns with STC.

The interrupt routines called require knowledge as to the particular hardware SIBO channel being used by the driver at the time an interrupt occurs. This information is passed through to the GenSetRevector function in StartInterrupts by loading the address of the appropriate Int Vec routine from the A4ExifChannelIntVec field of the channel StatusEnt struc. As a result, when an interrupt occurs, the currently loaded IntVec routine is invoked. All the Intvec routines reload DI with the appropriate address of the channel StatusEnt in the device driver code segment before falling through to the common interrupt routine service code held in ComInt.

Comint

Revision 1.00 Page 73 of 115 pages

The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

The common interrupt service routine code resides in the ComInt vector. The structure of this code is presented below. It should be emphasised that no data in the application data space and hence in the open channel control block can be accessed from ComInt. This explains why it is necessary for the OS to invoke a wait handler to clean up after the interrupt service routine code for a particular asynchronous I/O request has been run.

e Check the value held in the chanReadCompleted flag

e If this value is 2 then we do not have an asynchronous read completed but rather the interrupt line has been pulled low outside of an asynchronous I/O request.

e If this value is 1 then we have an asynchronous I/O request completed and so IoSignalByPidNoResched must be invoked to signal to the OS that a read has completed.

e In both cases, sense the status and LED bytes from the Example Interface hardware and load these values in the device driver's code segment A4ExifStatusEnt struc.

e There are four possibilities of status byte corresponding to the four combinations offered by the two input switches, S1 and S2. These are used to output one of four separate LED bytes to the LEDs.

e Awrite to AlNonSpecificEoi register (or A9BNonSpecificEoiW in the case of an ASIC9 machine) must be done prior to exiting to let the OS know that the installed interrupt service routine has terminated.

Other important local device driver functions

The functions presented in this section are local to A4EXIF.LDD and perform various important tasks relating to the peripheral hardware such as groping the hardware and setting interrupts running. Since these tasks have to be undertaken by most device drivers, the relevant functions are outlined in greater detail.

A4ExifCheckHardwarePresent

Every Psion device driver has a characteristic 'CheckHardwarePresent’ or 'GropeHardware" function that usually involves checking for the presence of the required peripheral device by means of comparing a couple of ASIC4 identification bytes returned by the peripheral in response to a SIBO serial protocol identification message with the expected answers. The specific value of the InfoByte is unimportant as long asa "test al, al" call is made which will always return a non-zero answer if ASIC4 is present. In that case, the extended info byte should be tested for against what is expected from address lines A23-A27.

Psion Workabout/HC machines have three physical serial links and two of these are accessed via the SSD slots. The third link corresponds to the serial expansion port. In order for a driver to talk to a peripheral connected to this port, it must specifically select this serial link. In order to prevent multiple access to a single peripheral, it is necessary in the first instance to check whether the serial channel is free or not. A call to the operating system function HwGet Channel with the appropriate interrupt mask in AL returns with CLC if the channel was captured successfully. Logically this call should be made in the Open vector but since it can only sensibly be made after the hardware has been successfully located it can be placed at the end of the GropeHardware function. A corresponding call to HwFreeChannel must be made when closing the channel. To actually select a channel prior to communication along it, a call to HwSelectChannel Is necessary.

A4ExifStartChannelRunning

This function is called at the end of the Open vector to set the ASIC4 Example Interface hardware running. It can also be invoked by the Hold vector. The function first checks the status of the global StatusEnt ChannelRunning flag. If this flag is clear, CheckHardware is called to determine whether the hardware is still connected and then StartInterrupts is called before the channelRunning flag is

Revision 1.00 Page 74 of 115 pages

The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

set to indicate that the channel hardware has been started. The function returns with CLC on successful completion or with STC if no hardware was located.

A4ExifStopChannelRunning

This function simply clears the channelRunning flag if set and calls StopInterrupts unless the channel already has its ChannelRunning flag clear. The StopChannelRunning function will be called by Strategy vector when trying to close a channel and can also be called by the Resume vector.

A4ExifStartinterrupts

StartInterrupts is called whenever a call is made to StartChannelRunning. At the heart of the function is a call to the OS GenSetRevector function which is used to install a specified interrupt service routine in the place of the default routine held in the interrupt vector table. GenSetRevector is called with the interrupt vector number of the service to be replaced in AX and the offset and code segment of the replacement interrupt vector service in BX and CX respectively. BX is loaded from the ChannelIntVec field of the channel StatusEnt which holds the name of the specific interrupt service routine code (i.e. IntVecO, IntVec1 etc.). The latter functions set up the appropriate channel- specific variables before falling through to the common ComInt routine. The channel interrupt mask which is machine and channel dependent is written to the appropriate register on the host ASIC. In the case of ASIC9, this register will be A9BInterruptMaskRW. For ASIC1 it will be AlInterruptMask.

A4ExifStopInterrupts

StopInterrupts reinstalls the original interrupt service routine by invoking the GenResetRevector OS system service and signalling the interrupt mask to the corresponding host ASIC register.

Structures and Include files

Epocdef.inc and device driver strucs

Epocdef.inc is an important header file that contains the definitions of various strucs extensively used in the construction of device drivers. It also contains the definitions of all the OS error values such as DeviceErr and NameErr that are used in A4EXIF.LDD to communicate an error to the application via AX. Listed below and overleaf are the key strucs defined in Epocdef.inc that were used in the coding of A4EXIF.LDD.

LibEnt struc Start of device driver LibSignature dw ?

LibInfo dw 2

LibCount dw ?

LibBase dw ?

LibEnt ends

OpenEnt struc Pointed to by SI in Open vector OpenNamePtr dw ?

OpenMode dw ?

OpenChan dw ?

OpenEnt ends

ChanEnt struc Used in open channel control block ChanSignature dw 2

ChanNext dw ?

ChanLibHandle dw ?

ChanEnt ends

IntEnt struc Pointed to by BP in Open and Strategy vectors IntFrame dw ?

IntBP dw ?

IntES dw 2

IntDS dw ?

Revision 1.00 Page 75 of 115 pages

The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

IntPC dw ? IntCs dw 2 IntFLAGS dw ?

IntEnt struc ends

RqEnt struc Pointed to by SI in strategy vector RqFunction dw 2 RqA1Ptr dw ? RqA2Ptr dw ? RqStatusPtr dw ?

RqEnt struc ends

A4EXIF channel strucs

These are defined at the start of the A4EXIF.LDD code segment. The open channel control block is held in a structure of type A4ExifEnt and is allocated space from the heap of the process invoking the device driver's open vector. As such, it cannot be accessed from the Hold, Resume and Reset vectors or from the interrupt service routine, ComInt. The channel StatusEnt holds various key channel related flags. Each hardware channel has its own StatusEnt which is instantiated in a header in the device driver code segment following the LibEnt structure. This header block is usually held in CS:DI which is how the StatusEnt variables are accessed. The structure of both A4EXIF channel strucs is shown below:

A4ExifEnt struc OPEN CHANNEL CONTROL BLOCK A4xifIo ChanEnt<>

A4ExifHandlerPtr dw ? Pointer to the Wait Handler A4ExifStatus dw ? Address of I/O request status word A4ExifAlPtr dw ? Pointer to first argument

A4ExifA2Ptr dw 2. Pointer to second argument A4ExifStatusEntPtr dw ? Pointer to channel's StatusEnt A4ExifTickHandle dw ? Handle to the TCK device channel

A4ExifEnt ends

A4ExifStatusEnt struc CHANNEL STATUS_ENT

A4ExifChannelPid db ? Process id of process holding channel open

A4ExifChannelOpen db 2 Is the channel open or not? A4ExifChannelRunning db ? Is the channel running? A4ExifChanReadCompleted db ? Flag used to indicate to handler when

A4ExifChanneliIntMask db ? Contains the HW channel interrupt mask A4ExifChannelIntNum db ? Holds no. of interrupt vector to be replaced

A4ExifChannelSelect db 2 SIBO channel select flag A4ExifChannelDummy db 2 Spare

A4ExifChanneliIntVec dw ? Holds replacement int. vector routine name

A4ExifStatusEnt ends

Ossibo.inc and Ospack.inc

Ossibo.inc is an important header file that contains the defines for all the ASIC2 and ASIC9 register addresses. Ospack.inc contains similar information but for ASIC4.

Revision 1.00 Page 76 of 115 pages

The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

12. AN EXAMPLE DEVICE DRIVER FOR ASIC5: SYS$AS5.PDD

Introduction

In this chapter, the functionality and code structure an example installable physical device driver, SYS$AS5.PDD, is presented in some depth. Circuit details of the corresponding Psion peripheral for this driver, the Psion 3-link, were outlined in chapter 8. SYS$AS5.PDD enables software written using the Psion SDK to communicate with the 3-link peripheral through means of standard PLIB calls such as ‘p_open' and 'p_write'. This peripheral incorporates an ASICS as the SIBO serial protocol slave device. As explained earlier in chapter 7, ASICS has an on-board 16550 UART which means that it can be used in conjunction with the standard serial LDD provided an appropriate PDD is loaded. SYS$AS5 is a PDD intended for this purpose and its description in this chapter provides a clear insight into the generalised structure and construction of physical device drivers for peripherals based around the SIBO architecture.

The LDD-PDD interface

All Psion device drivers have a LibEnt structure at the head of their code segment which includes a vector table defining the functionality of the driver. In the case of SYS$AS5, four vectors are defined. These are: Install, Remove, Open and Strategy. The structure of the first three of these are fixed for most device drivers but the fourth can be specified in any way. This fourth vector defines the LDD- PDD interface and is constructed to allow the two drivers to best communicate with each other. In the case of serial PDDs, the approach taken is modelled on the LDD strategy vector with the corresponding strategy vector table and function numbers. This is a logical choice but it is important to emphasise that the LDD-PDD interface is completely user-definable and that the approach described in this chapter is optional.

The key feature of any LDD-PDD interface is that the LDD must have no explicit concept of hardware. In the case of the serial LDD, for instance, it knows that it has a serial port that it can read data bytes from or write data bytes to but it is ignorant of the explicit implementation of the hardware at this port. That aspect is handled by the corresponding PDD which handles all the specifics of data byte I/O. In the case of an application writing a buffer to the serial port by means of a p_iow(P_FWRITE....) call, for instance, the LDD will first copy the data in the application's DS into a local CS buffer. It will then call the PDD to indicate that it intends to start sending data bytes when the PDD is ready to start receiving. When the PDD is ready to commence sending a byte out of the serial port, it calls a function (TransmitByte) in the LDD. This function reads the next byte to be transmitted from its local buffer and hands it to the PDD. The PDD duly transmits the byte and again calls TransmitByte until all the bytes are completed. The LDD then sends a special 'NothingToSend' signal to the PDD which indicates that transmission is finished. The LDD also sends an IoSignalByPidNoResched which causes its wait handler to be invoked by the OS. In this way, the IoSignal that signifies completion of the original write request is invoked by the LDD. Note that the LDD has no concept of interrupts, merely of sending a byte at a time and registering completion or otherwise of I/O requests. Futhermore, the PDD never takes the initiative from the LDD and merely undertakes one function at a time before returning control back to the LDD. The LDD-PDD interface is examined in greater depth later in this chapter when the structure of the PDD strategy vector is presented.

Revision 1.00 Page 77 of 115 pages

The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

Code Structure

Device Names and Loading SYS$AS5.PDD

SYS$AS5.PDD is loaded into the RAM of the host machine by means of the following PLIB call in the application code:

p_loadldd("SYSS$AS5.PDD") ;

The name of a device driver is the mechanism by which an application can obtain a channel to that device driver. LDDs all have three character names followed by a period, a further three characters and acolon. The first three characters of a PDD name are the name of the LDD to which the PDD belongs. The second set of three characters uniquely identify the PDD. The device name is required to uniquely identify the LDD to the OS when attempting to open a channel on it. The SYS$AS5 PDD belongs to the "TTY:" LDD. Its name as defined in its LibEnt structure is 'TTY.SR5'. Thus a channel with its handle in pcb may be obtained on it at the application level by means of the following call:

p_open (&pcb, "TTY.SR5:A",-1);

The qualifier after the colon indicates that the driver can support more than one channel. Channels are allocated a single character sequentially from the character 'A' up to the character 'C'. The number of channels that can be supported in this way is dependent upon the host hardware. Only one expansion port can be opened on the S3a for instance whereas three are possible on the Workabout and HC. EPOC uses the driver name in the p_open call to invoke the ToOpen system service which in turn invokes the Open vector on the associated device driver.

The Single Code Segment and Data Storage

All data associated with a physical device driver must be stored in its code segment. Examples of such data are the channel interrupt masks and numbers that have to be visible to all processes that may be using SYS$AS5.PDD.

The overall structure of the code segment is typical of Psion physical device drivers. The segment begins with a CodeSeg directive followed by the LibEnt structure which defines all the device driver functions. Before entering the code for these functions, all global variables are declared in the internal (CS) data space. Following the code for the LibEnt functions comes the code for all the local driver functions, After these are the EndCodeSeg and end OsAs5PDD directives.

The Channel struct and A5Ent struct

At the head of the driver's assembler source file, SYS$AS5.ASM, various constants, compiler defines and types are listed. It is here that templates are declared for the global structures that hold the key driver variables. in the case of SYS$AS5, one main structure, the Sr5ChannelStruct, is employed to hold the various important flags and masks that relate to the status of each separate channel on the driver. This structure is termed the Channel struct and its fields are filled in during the course of running the PDD install and open vectors. Whenever the serial LDD invokes one of the PDD functions, the application must ensure that CS holds the address of the PDD's code segment which is where the Channel struc resides. The channel's Channel struct is usually accessed through DI or BX depending on preference. Its layout is presented later in this chapter along with other important defines that were used in the construction of SYS$AS5.PDD.

SIBO hardware and conditional compilation

As indicated previously, the number of expansion channels supported by a host Psion machine is dependent on the hardware. In the case of the S3a, only one SIBO channel can legitimately be opened corresponding to expansion port A. With the HC and the Workabout, it is possible to open up to three separate SIBO channels on ports A through to C. SYS$AS5.PDD is constructed to enable it to run on any host Psion platform. In its internal data space, the various hardware options for the SIBO channels, interrupt masks and interrupt numbers are coded in a large if statement thereby

Revision 1.00 Page 78 of 115 pages

The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

permitting conditional compilation of the driver for the required host hardware. The only change that need be made in adapting it for use on another Psion machine is the alteration of the build flag at the start of the code segment. This flag indicates to the compiler which SIBO machine flags as well as other variables should be set. The conditional compilation table outlined here is worthy of some study because it encapsulates all the information regarding masks and SIBO hardware channels required by the prospective developer interested in constructing a multi-platform peripheral and accompanying PDD.

The PDD Functions

OsAS5install IN: Nothing OUT: If successful, return with carry clear If installation unsuccessful, return with the carry flag set and error number in the AL register

PRESERVE: SS, SP, BP

The install vector is called by the parent LDD whenever the PDD is required to be loaded. It cannot be called directly be an application only indirectly through the LDD in its Install vector. The install vector is called in the context of the OS with DS and ES in an unknown state. Memory will not be moved while in this function so the normal rules governing the use of ES and DS may be ignored.

OsAS5Remove

IN: Nothing OUT: If successful, return with carry clear

If installation unsuccessful, return with the carry flag set and error number in the AL register

PRESERVE: SS, SP, BP

The remove vector is called by the parent LDD whenever the PDD is required to be unloaded. It cannot be called directly by an application and only indirectly through the LDD in its Remove vector. The remove vector is called in the context of the OS with DS and ES in an unknown state. Memory will not be moved while in this function so the normal rules governing the use of ES and DS may be ignored.

OsAS5Open IN: SS:SI points to the OpenEnt structure ES, DS point to the DS of the application process. OUT: If successful, return with carry clear and control block in BX If installation unsuccessful, return with the carry flag set and error number in the AL register

PRESERVE: SS, SP, BP

The open vector is called by the parent LDD whenever a channel to the PDD is required to be opened. It cannot be called directly by an application and is typically invoked in the higher level LDD Open vector code by means of the DevOpenPpp OS system call. On invoking the open vector, SI points to the OpenEnt structure which contains three fields, namely OpenNamePtr, OpenMode and OpenChan. The OpenNamePtr points to the qualifier immediately following the device name in the call to p_open. In the case of SYS$ASS5, for instance, the OpenNamePtr would point to the 'a' in the name "TTY.SR5:A". This corresponds to an attempt to open the first hardware SIBO channel on the host machine which if successful will leave the address of the ChanO Sr5ChannelStruct in BX. The PDD open vector finally includes a call to the OS service HwGet Channel to obtain the requested SIBO channel.

Revision 1.00 Page 79 of 115 pages

The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

The order of action undertaken by the parent serial LDD's open vector is generally fairly complicated and includes various calls to the PDD strategy vector routines. The situation is outlined overleaf:

e Ensure that the LDD itself can be opened.

e Call the PDD open vector using the OS DevOpenPDD OS call.

e = If successful, call the OS service DevGet PDDAddress which returns the full segment:offset address of the PDD's fourth strategy vector in BX:AX. These values are loaded into the dword Channel struct field SerialPDDEntry.

e Invoke the PDD strategy Open and SetHandlerCS functions to set up offsets and segments respectively to locations in the LDD above.

e Invoke strategy Set to initialise the transmission baud rate.

e Invoke strategy Start to set-up and then enable interrupts

Once the DevGetPDDAddress service has been used to load the LDD's SerialPDDEntry field, it may be used to load in the address of any of the PDD's strategy functions. The DevGetPDDAddress OS call invoked in the LDD open vector must also be invoked in the LDD resume vector code since memory may have been moved while the LDD was held. The PDD is ignorant of such activity since the serial LDD is responsible for handling all holds and resumes.

OsAS5Strategy IN: AX holds the vector number ES, DS point to the DS of the application process. OUT: If successful, return with carry clear and control block in BX If installation unsuccessful, return with the carry flag set and error number in the AL register

PRESERVE: SS, SP, BP

The strategy functions are invoked directly from the various serial LDD vectors to provide hardware- specific services. For instance, in order to set up the baud rate, it is necessary to invoke strategy Set. The strategy vector table for OsAS5Strategy is presented below and then the functionality of the important component vectors is outlined:

AS5StrategyJumpTable label word

dw offset AS5Open ;Load Handler offsets

dw offset AS5Close ;Close the channel

dw offset AS5Start ;Start the channel

dw offset AS5Stop ;Stop the channel

dw offset AS5Set ;Set the channel status

dw offset AS5Sense ,;Return channel status dw offset AS5Control ;Drive the handshaking lines dw offset ASS5Enquire ;Returns baud rate

dw offset AS5Enable ;Begin sending output dw offset ASS5SetHandlercCs ;Load Handler segments

Open and SetHandlerCS go together and are invoked from the LDD open and resume vector code. Both are required to let the PDD know the address at which its LDD resides. The four full addresses passed through to Open and SetHandlerCS are of the LDD's control block and the LDD StatusInt, RecvInt and XmitInt vectors. Close is called in order to close an opened channel. Start and Stop are used to enable/disable interrupts and are invoked from the LDD open, hold/resume and set vectors. The order of action in the PDD Start vector is as follows: e Initialise PDD variables e Check H/W present e Start the hardware running. In the case of SYS$ASS5, part of this process involves starting a continuous clock from the host controller ASIC in order to trigger the UART clock on the 3- link's ASICS. In addition to this clock, the RTS and DTR lines must be driven low. e = Start interrupts. The common interrupt service routine code resides in the PDD ComInt function. This code is patched into the interrupt vector via the GenSetRevector system service. The interrupt mask contains bits to

Revision 1.00 Page 80 of 115 pages

The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

generate the following interrupts: Receive character, Ready to send next character and Modem line change character. In SYS$ASS, all three interrupts are enabled in Start. It is important to realise that after masking in these bits, a Ready to send next character interrupt is almost immediately generated so the corresponding ComInt code must be able to handle this.

CheckHardwarePresent

This non-mandatory function is called from the Open vector and follows the lines of previously discussed CheckHardwarePresent code. After checking for an ASICS at the end of the serial link, the function returns with the carry flag clear if one is found. If a non-zero info byte is returned with an Asic5Normalld, then various other IDs are tried (Asic4Id, Asic8Id, Asic5PackId) before returning with the carry flag set.

CheckHardwarePresentFromStart

This is a non-mandatory function called only from the PDD Start vector. After checking that we have an ASICS at the end of the SIBO channel, the function sets the S_PERIPHERALMODE bit of the A5PortBMode register. This then puts ASICS into UART mode.

Comint

The common interrupt routine code is entered with DI holding the address of the appropriate channel struct. ASICS's control register (A5CtrlReg) is read first to determine which interrupt has occurred. The byte read from the register is compared against S_ MDINT (Modem lines interrupt), S_RXINT (Receive character interrupt) and S_TXINT (Transmit interrupt). The code to handle each of these cases is then entered prior to returning control back to the LDD via the Channel struct fields that were filled by a previous LDD calls to the PDD strategy Open and SetHandlersCS vectors. The LDD has no knowledge of interrupts and the purpose of ComInt is therefore to hide the hardware details of handling interrupts from the LDD. Once the interrupt has been serviced, a write is made to A9BNonSpecificEoiW in the case of ASIC9 or AlNonSpecificEoi for an ASIC1/ASIC2 based system to indicate to the OS that the interrupt has been serviced.

Revision 1.00 Page 81 of 115 pages

The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

13. DEBUGGING AND TESTING DEVICE DRIVERS

Introduction

This chapter will detail the techniques that can be used by the developer to first debug and then test device drivers. The emphasis will be on the software methods such as: Good use of variables. e.g. Starting all the fields in the CS Channel Status structure with CS. e Debugging by eye. Even more important with regard to device drivers. e Using SDBG. The pitfalls and benefits. Working your way around the strategy vector calls with SDBG. e Construction of C test harness programs. Catching all the error flags that can be returned by device driver functions. e The comprehensive memory check program mem.c.

Debugging Techniques

A Psion device driver is written in 8086 assembler as an asm file and built using the Borland Turbo Assembler compiler. The subsequent debugging process centres around the construction of an appropriate PLIB test harness. The purpose of a test harness is to check a number of the device driver vectors to ensure that they do not return errors or cause panics. The majority of PLIB calls that would be used in this context return a negative integer that is used to ascertain the cause of the problem in the corresponding device driver vector. The code below, for instance, would be used to test the install, open, strategy close and remove vectors of the A4EXIF LDD:

GLDEF_C VOID main(VOID) {

VOID *serH;

INT ret;

if ((ret=p_loadldd("A4EXIF.LDD") ) <0) { p_printf ("Error %d on p_loadldd", ret); p_getch () p_exit (0) }

else p_printf ("Successfully loaded A4EXIF.LDD");

if ((ret=p_open(&serH, "LED:",-1) ) <0) { p_printf ("Error %d on p_open", ret); p_getch();

x

else

p_printf ("Successfully opened LED: channel"); p_close(serH) ; p_printf ("Successfully closed LED: channel"); }

p_devdel ("LED",E_LDD) ;

p_getch();

p_exit (0);

}

Revision 1.00 Page 82 of 115 pages

The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

If as often happens at this stage, a bug in the device driver causes the test harness program to crash, it is necessary to debug the driver code either by eye or using SDBG. Debugging by eye should always be the first resort, however, whenever the bug can be readily pinned down to a particular vector. Things to look out for include:

e ~=An unbalanced stack: Check that the number of 'pushes' equals the number of 'pops' in the appropriate vector code.

e Addressing the wrong location: Ensure that all the Channel status fields (stored in CS) are offset using the correct register and that that register holds the right value. The following code for instance requires DI to hold the address of the channel status struct prior to

invocation: mov al, cs: [di].ChannelOpenFlag

e Consistency: With regard to the last point, it is important to be consistent if possible and try and use the same register (i.e. DI) to hold the channel status structure. A different one (usually BX) should also be used to hold the address of the open channel control block.

e Trashing BX and DI: If these registers are used in the vector code for anything other than addressing, check that their value is not being trashed by the operation.

Debugging using SDBG is an extension of debugging by eye. The SIBO debugger allows the programmer to trace through the driver's source code instruction by instruction and observe the contents of the CPU registers in the process. In this way it is possible to discover any discrepancies in terms of the values stored in the various registers. Furthermore, tracing with SDBG will enable the user to pinpoint the source of panics. The first objective of the device driver debugging process should be to get the code outlined on the previous page to work OK.

Further Testing Strategies

Once installing, opening, closing and unloading are dealt with, a test harness can be expanded to include p_iow or p_ioc calls which map onto the LDD's strategy vector. At this stage, SDBG is particularly useful for testing purposes as breakpoints can be set and jumped to. In this way for any p_ioc(serH, <func>, &serStat, &Al,&A2) call, the contents of the status word, serStat, and the A1 and a2 parameters can be tracked through the LDD's strategy vector. The value held by the status word at the end of a particular strategy call is the value returned by the corresponding PLIB p_iow/p_ioc call. Thus negative errors within the strategy code can be picked up by the test harness. A good test harness should be able to catch all the possible errors and at the least invoke p_printf to let the user know when one of them is returned. The file p_file.h contains a list of all the current return error values and the corresponding PLIB level error name. The entry for PendingErr, for instance is as follows:

#define PendingErr (-46) #define E_FILE_PENDING PendingErr

In order to induce the return of these error values it is necessary to extend the basic test harness outline to allow the user to undertake various pathological actions. For instance, the harness may include code that tries to open a channel twice which should result in InUseErr being invoked. By such means it is possible to ensure that a driver is not only operating as it should in normal circumstances but returning the correct error value when relevant.

Memory Testing

The final process that should be undertaken to fully test a device driver consists of the construction of an appropriate memory test harness. Three functions are presented on the next two pages which provide the core of such a comprehensive memory test program. The first function, CheckMemory, uses the PLIB routines p_allspce and p_sgfree to print out the current free bytes on the heap and the number of free segments in the host RAM. This function can be invoked after installing, opening, closing or removing a device driver to ensure that memory is not going to ‘alloc heaven’. The GobbleMemory function is first used to determine the amount of free memory available in segments

Revision 1.00 Page 83 of 115 pages

The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

through calling p_sgfree. The PLIB p_sgcreate function is then invoked to create a new segment, "Test", that consists of all of this free memory. Finally, the p_sgcopyto PLIB function is called to fill "Test" with Ox55's. By using up all free memory in this way, it is possible to use segment "Test" to determine whether a particular driver vector is writing to the wrong location. TestGobble, presented overleaf, is the third function outlined. It uses the PLIB function p_sgcopyfr to check the values of the bytes in the segment "Test". If any of the 0x55's have been overwritten then we know that we have a problem. These three functions should be incorporated within the standard test harness functions already presented in this chapter. In this way, it is possible to generate a powerful generic test program that can be used as the basis for all device driver testing.

LOCAL_C VOID CheckMemory (VOID) {

VOID *Heap;

INT fbytes;

fbytes=p_allspc (&Heap) ;

p_printf ("Free Heap Memory =>%x bytes", fbytes) ; p_printf ("Free Segments =>%d",p_sgfree()); p_getch();

}

[KR KR KK KR KK KI KK IK I I I I /

LOCAL_C VOID GobbleMemory (VOID) { UINT nParas, segSize; INT 3;

LONG pos,i;

UBYTE buf [256];

p_printf(" System RAM size = %d",p_getram()); p_printf ("Internal RAM usage = %d",p_sgramdisk())j; nParas=p_sgfree()j; p_printf ("Amount of free RAM = %d",nParas); segH=p_sgcreate("Test",nParas, E_SEGMENT_HIGH) ; if (segH)

p_printf ("Created segment \"test\"");

else { p_printf ("Error in creating segment"); p_getch(); p_exit (0); } segSize=p_sgsize(segH) ; p_printf("Size of segment is %d",segSize); p_printf("In 16-byte paragraphs"); p_sleep(5L); for (j=0; j<16; j++) buf [j]=0x55;

i=0; while (i<segSize) { pos=i*16; if (p_sgcopyto(segH, pos, &buf [0],16) <0) { p_printf ("Failed on p_sgcopy"); p_printf ("%d",i); p_getch(); } i++; } p_printf("Test segment full of 0x55s"); p_getch(); }

[RRR KK KK KK KKK IK I I I I /

Revision 1.00 Page 84 of 115 pages

The Psion SIBO Hardware Development Kit

LOCAL_C VOID TestGobble (VOID)

UINT segCount; buf [16];

segCount=0; p_printf ("Checking segment integrity ..."); for (segCount=0; segCount<p_sgsize(segH); segCount+t+) { if (p_sgcopyfr(segH, segCount*16, &buf [0] ,16) <0) p_printf ("Error in segment");

else { for (i=0;i<16;i++) if (buf[i] !=0x55) { p_printf ("OVERWRITE ERROR!"); p_printf ("Segment count=%d",segCount) ; p_printf ("Byte count=%d",i); } } } p_printf ("Test segment OK"); p_printf ("Heap integrity checks OK"); p_allchk (44); p_printf("If get here, heap OK"); p_getch();

}

[KR KR KK KR KK KKK I I I I I /

Revision 1.00

Psion PLC (c) May 1995

Page 85 of 115 pages

The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

APPENDIX: SOURCE CODE FILES

A4EXIF.ASM

title A4EXIF -- Example ASIC4 Interface device driver subttl Copyright (c) Psion PLC (1994) name A4EXIF ; ; VER DATE BY DESCRIPTION jo -o-------------------------------------- 7 1.00F 26/1/95 Mal Working Version BUILDSB=1 7S3a build environment (channels=1) S3c=0 ;Need to specify no s3c ; BUILDSC=1 7S3c build environment (channels=3) ; BUILDCH=1 ;HC build environment (channels=3) ; BUILDHH=1 753 build environment (channels=1) include ..\inc\epoc.inc include ..\inc\epoclib.inc include ..\inc\epocsibo.inc

include ossibo.inc include ospack.inc

Example Logical Device Driver for prototype LED-ASIC4 Interface circuit for Corporate/S3C/Consumer serial port. Written by Mal Dec 1994/Jan 1995.

Me oNe Ne

A4EXIF CONSTANTS AND TYPES

The following constants and type definitions are compiler directives used by the TCEP assembler when it is creating the LDD.

Ne Ne Ne Ne Ne

if Consumer

numberofchannels equ 1 else if Corporate or S3c numberofchannels equ 3 else numberofchannels equ 2 endif endif

7;Channel StatusEnt block accessed through CS:DI A4ExifStatusEnt struc

A4ExifCSProcessId dw <i ;Channel parent process id A4ExifCSChannelOpen db 2 ;Channel open flag A4ExifCSChannelRunning db ? ;Channel hardware running flag A4ExifCSChanReadCompleted db 2 ;Channel request completed flag A4ExifCSChannelIntMask db 2 ;Channel interrupt mask A4ExifCSChanneliIntNum db ? ;Channel interrupt number A4ExifCSChannelSelect db 2 ;SIBO Channel select A4ExifCSChanneliIntVec dw ? ;Channel int vector number A4ExifCSTickHandle dw ee ;TCK channel handle A4ExifCSA1Value db i ;Channel strategy Al parameter A4ExifCSA2Value db ? ;Channel strategy A2 parameter

A4ExifStatusEnt ends

;Open Channel Control block accessed through DS:BX A4ExifEnt struc

A4ExifDSIo ChanEnt <> 7;Open channel control block Ent A4ExifDSHandlerPtr dw 2 ;Cant touch when under A4ExifDSStatusPtr dw ? ;Hold, Resume, Reset or A4ExifDSA1Ptr dw ? ;interrupt routine A4ExifDSA2Ptr dw es A4ExifDSStatusEntPtr dw ?

A4ExifEnt ends A4PERIPH MASK equ Of0h 711110000b

Revision 1.00 Page 86 of 115 pages

The Psion SIBO Hardware Development Kit

EXTENDED_INFO_BYTE equ 090h U5_ENABLE_ON equ 080h U5_ENABLE_OFF equ 000h ;Latch addresses for reading/writing USOUTPUT_LATCH equ 00000000b U3INPUT_BUFFER equ 00000000b U4STATUS_BUFFER equ 00000001b cs: [di] .A4ExifCsAlValuefor INTERRUPT_LATCH equ 00000001b ;Status byte masks S2S3_ON equ 00000011b S2S3_OFF equ 00000000b S2_ONLY equ 00000001b S3_ONLY equ 00000010b INTERRUPT_STATUS_MASK equ 00000011b 7; LED bytes SOME_LEDS_ON equ 01010101b SOME_LEDS_OFF equ 10101010b TOP_LEDS_ON equ 11110000b BOTTOM_LEDS_ON equ 00001111b ZERO_BYTE equ 00h dgroup group stack assume ds:dgroup,es:dgroup,ss:dgroup CodeSeg 7 A4EXIF ENTRY TABLE ; Seseseo eee ee sececs ProcBegin@ A4ExifLDD ; ssieceees dw LDDSignature db 'LED',0,0,0,0,0 dw (VectorEnd-Vector) /2 Vector: dw A4ExifInstall dw A4ExifRemove dw A4ExifHold dw A4ExifResume dw A4ExifReset dw A4ExifUnits dw A4ExifOpen dw A4ExifStrategy VectorHandler: dw A4ExifHandler if Asic9 InterruptVectors: dw A4ExifTickInt endif VectorEnd: H A4EXIF INTERNAL DATA SPACE , ; Device Driver global variables follow. ; These variables reside in the code segment ; and as such can always be accessed with 7 the 'cs:' prefix.

if Asic9 if Consumer

Channel0O A4ExifStatusEnt<0,0,0,0,mask

Psion PLC (c) May 1995

710010000b 7;Sets LBO for latch U5 ;Deselects LBO for U5

;Selects ;Selects ;Selects

;Selects

A9MSlave, HwIrq2Revector, SelectChannel5, IntVec0O,0,0>

else if Corporate or S3c

Channel0 A4ExifStatusEnt<0,0,0,0,mask

AOMExpIntA, HwIrq4Revector, SelectChannel3, IntVec0O,0,0>

Channell A4ExifStatusEnt<0,0,0,0,mask

AQMExpIntB, HwIrq5Revector, SelectChannel4, IntVec1,0,0>

Channel2 A4ExifStatusEnt<0,0,0,0,mask

A9MSlave, HwIrq2Revector, SelectChannel5, IntVec2,0,0>

Revision 1.00

AO for writing AO for reading

; reading Al for writing

Page 87 of 115 pages

The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

else Channel0 A4ExifStatusEnt<0,0,0,0,mask

AOMExpIntA, HwIrq4Revector, SelectChannel3, IntVec0O,0,0> Channell A4ExifStatusEnt<0,0,0,0,mask

AQ9MExpIntB, HwIrq5Revector, SelectChannel4, IntVec1,0,0> endif endif else if Consumer Channel0O A4ExifStatusEnt<0,0,0,0,mask

Asic2Int, HwIrq4Revector, SelectChannel7, IntVec0,0,0>

else if Corporate ChannelO A4ExifStatusEnt<0,0,0,0,mask ExpIntLeftA, HwIrq3Revector, ExpChannelLeftA, IntVec0O,0,0> Channell A4ExifStatusEnt<0,0,0,0,mask ExpIntRightB, HwIrq2Revector, ExpChannelRightB, IntVecl1,0,0> Channel2 A4ExifStatusEnt<0,0,0,0,mask Asic2Int, HwIrq4Revector, SelectChannel7, IntVec2,0,0> else ChannelO A4ExifStatusEnt<0,0,0,0,mask ExpIntLeftA, HwIrq3Revector, ExpChannelLeftA, IntVec0O,0,0> Channell A4ExifStatusEnt<0,0,0,0,mask ExpIntRightB, HwIrq2Revector, ExpChannelRightB, IntVecl1,0,0> endif endif endif HoldFlag db 0 ;Hold/Resume flag SwitchStatus db ? ;Holds the masked status byte from U4 after interrupt ProcEnd noret ProcBegin@ A4ExifInstall, far ; eee ; Installs the device driver. 7 Invoked after a PLIB 'p_loadldd("A4EXIF.LDD")' call to load the LDD ; All of the fields inside the CS control blocks are preloaded ; with the correct values at install time. Install therefore does ; not do any work. 7 IN: ; Nothing 7 OUT: ; Carry Clear - driver successfully installed 7 cle ;The ChannelOpen fields are set to zero ret ;in the relevant ChannelStatusEnt headers ProcEnd noret ProcBegin@ A4ExifRemove, far ; eSeseces eee ; Removes the device driver. ; Invoked after a PLIB 'p_devdel("LED",E_LDD) 'call to unload the H device driver. ; A device driver cannot be removed if any of its channels i are still open. H IN: ; Nothing H OUT: ; Carry clear - successfully removed 7 Carry set - remove failed, error number in AL 7 mov cx, numberofchannels ;Check that each mov di, offset Channel0O ;channel is closed xor ax, ax CheckAl1lChannelsClosedLoop: cmp cs: [di] .A4ExifCSChannelOpen, al ;Closed channels will jne WeHaveAChannelOpenSoFail ;have the value 0 in add di, (size A4ExifStatusEnt) ;their ChannelOpen

Revision 1.00 Page 88 of 115 pages

The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

loop CheckAl1ChannelsClosedLoop ;flags jmp FinishedOkay WeHaveAChannelOpenSoFail: mov al, InUseErr ;Fail if not all stc ;closed ret FinishedOkay: cle ret ProcEnd noret

ProcBegin@ A4ExifHold, far

v

; Called by the operating system whenever the device driver is

; being moved or the machine is powering down.

; This will also be called by our pack door polling function when

; it sees that the doors have been opened and our peripheral has

; lost power.

; IN:

7 Reason for the hold in AH

7 OUT:

7 Nothing

13 mov cx, 1 ;Hold can be called xchg cl, HoldFlag ;when the driver is cmp cl, 0 ;under a hold so jne AlreadyHeld ;re-entrancy blocking

A4HoldFromTick: ;is required mov cx, numberofchannels mov di, offset Channel0 ; Loop because Hold

HoldAllTheChannelsLoop:

;must stop all the

cmp cs: [di] .-A4ExifCSChannelOpen, ; channels je DontHoldBecauseNotOpen ;Is the channel open? push cx ;If it is then stop call StopTheChannelRunning yall interrupts pop cx DontHoldBecauseNotOpen: add di, (size A4ExifStatusEnt) loop HoldAl1lTheChannelsLoop AlreadyHeld: ret

ProcEnd noret

ProcBegin@ A4ExifResume, far

3 Called by the operating system when it has finished moving the - device driver in memory or when the machine is switching back on. ; Also called by our door polling routine when it sees that the doors ; have been closed and we can resume communication with our peripheral. ; IN: iH Nothing ; OUT: 7 Nothing is xor CX, cx ;Block in case of re-entrancy xchg cl, HoldFlag cmp cl, 0 je AlreadyResumed if Asic9 GenDataSegment ;Check to see if the pack HwGetSsdData ;doors are still closed mov bx, ax cmp es: [bx] .SsdDoorStatus, DoorOpen je DoorsAreOpen endif A4ResumeFromTick: mov cx, numberofchannels ; Loop because resume must mov di, offset Channel0 ;restart each open channel ResumeAllTheChannelsLoop: cmp cs: [di] .A4ExifCSChannelOpen, 0 ;Is the channel open? je DontResumeBecauseNotOpen push Cx call StartTheChannelRunning pop cx DontResumeBecauseNotOpen: add di, (size A4ExifStatusEnt) loop ResumeAl1lTheChannelsLoop AlreadyResumed:

Revision 1.00 Page 89 of 115 pages

The Psion SIBO Hardware Development Kit

Psion PLC (c) May 1995

ret

DoorsAreOpen:

mov HoldFlag, 2 ret ProcEnd noret

ProcBegin@ A4ExifReset, far

Called when an application which opened a channel terminates without closing the device driver. A device driver, for each open channel, has to request that the operating system calls this function when the application terminates abnormally (ie without closing an open channel). Reset can supply one piece of identifying data which will be passed in CX. This would usually be the channel's number or CS control block pointer. Reset just needs to clear interrupts, hardware reservations, and free the channel. Any allocated space will be cleaned up for you by the OS. IN:

The device driver's handle in BX

The address of the status struc identifying the channel in CX

7 OUT: ; Nothing , mov di, cx cmp cs: [di] .A4ExifCSChannelOpen, 0 je NotOpenToReset call StopTheChannelRunning 7Stop interrupts mov al, cs: [di] .A4ExifCSChannelIntMask ;Free the reserved HwF reeChannel ;hardware mov cs: [di] .A4ExifCSChannelOpen, 0 ;The channel is now NotOpenToReset: ;free ret

ProcEnd noret

ProcBegin@ A4ExifUnits, far

Called to find how many open channels the driver will support

- In: ; Nothing - Out: H The total number of channels supported in AX , mov ax, numberofchannels ret

~

ProcEnd noret

ProcBegin@ A4ExifOpen, far

Opens a device driver channel. Invoked after the PLIB call 'p_open(é&appHandle, "LED:*",-1)'to open a channel to the device driver.

,

,

7

H Tn:

; OS device handle of the device driver in DX

; Pointer to the OpenEnt struc in SI

; Pointer to the IntEnt struc in BP

; DS,ES,SS point to the applications data space

i Out:

; Carry clear - BX holds the address of the open channel

7 Carry set - AL holds the error number

is cld ;Interrupts off to pushf ;prevent multiple apps oli ;calling open mov si, [si] .OpenNamePtr ; Simultaneously mov al, [sitl] CharToFoldedChar ;Read the unit no. cmp al, 'A' ;part of device name jb OpenNameErr ;to find which channel sub al, 'A' ;to open. eg "LED:A" cmp al, numberofchannels jae OpenNameErr xor ah, ah push ax ;Map the channel no. mov dx, (size A4ExifStatusEnt) ;to a channel control mul dx ;block in our CS pop ax 7; space

Revision 1.00

Page 90 of 115 pages

The Psion SIBO Hardware Development Kit

mov di, ax add di, offset Channel0O cmp cs: [di] .A4ExifCSChannelOpen, 0 je GetATickChannel popft mov ax, AlreadyOpenErr jmp ChannelAlreadyOpen GetATickChannel: mov cs: [di] .A4ExifCSChannelOpen, 1 mov cs: [di] .-A4ExifCSChannelRunning, 0 popft ife Asic9 jmp GetHardwareChannel else push ax mov ax, ((':' shl 8)+'K') push ax mov ax, (('C' shl 8)+'T') push ax mov bx, sp ToOpen jne GotATickChannel add sp, 6 mov ax, LockedErr jmp OpenFailed GotATickChannel: add sp, 6 mov cs: [di] .A4ExifCSTickHandle, ax push ax mov bx, ax mov ax, IoFuncStart mov ex, 1 push cx push cx push ax mov cx, (InterruptVectors-Vector) /2 push cx mov cx, sp ToWithWait add sp, 8 pop dx jmp GetHardwareChannel endif OpenNameErr: popft mov ax, NameErr jmp ChannelAlreadyOpen GetHardwareChannel: mov al, cs: [di] .A4ExifCSChannelIntMask HwGetChannel jne CheckHardwareNowThatSIBOChannellIsOpen mov ax, InUseErr jmp FreeTckAndExit FreeTckAndChannelHardware: mov al, cs: [di] .A4ExifCSChannelIntMask HwF reeChannel mov ax, DeviceErr FreeTckAndExit: if Asic9 push ax mov bx, cs: [di] .A4ExifCSTickHandle IoClose pop ax endif OpenFailed: mov cs: [di] .A4ExifCSChannelOpen, 0 ChannelAlreadyOpen: stc OpenExit: ret CheckHardwareNowThatSIBOChannellIsOpen: Proclid mov cs: [di].A4ExifCSProcessId, ax mov cs: [di] .A4ExifCSChanReadCompleted, 0 call CheckHardwarePresent jc FreeTckAndChannelHardware mov cx, (size A4ExifEnt) HeapAllocateCell jc FreeTckAndChannelHardware mov bx, ax

Revision 1.00

Psion PLC (c) May 1995

;Offset in DI

;Check to see if ;channel is already ;open

,Obtain a TCK channel so ;we can poll the door state

7;If HC, we don't need ;to set up the TCK ; routine

;Try to open "TCK:" ;channel with "TCK:" ; string on stack

;TCK will call our ,door-polling function 732 times a second

7Start our ,door-polling function ;running by starting ;the "TCK:" channel

7Frequency 1 tick ;Data irrelevant ;Handle to driver ;TCK function to call

7;Check the hardware ;is available then ;reserve it ;Returns with carry ;clear if OK

7Set up the calling ;process ID

;Returns with carry ;clear if successful ;Allocate a control ;block in our app's ;data space

Page 91 of 115 pages

The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

push bx ;IloAddHandler trashes BX mov al, (VectorHandler-Vector) /2 ;Set up our wait handler ToAddHandler ;Leaves the address of pop bx ;handler in AX jne GotHandler push ax ;If no handler, open fails HeapFreeCell pop ax jmp FreeTckAndChannelHardware GotHandler: mov [bx] .A4ExifDSStatusEntPtr, di mov [bx] .A4ExifDSHandlerPtr, ax mov [bx] .A4ExifDSStatusPtr, 0 mov [bx] .A4ExifDSIo.ChanNext, bx mov [bx] .A4ExifDSIo.ChanSignature, IoChanSignature mov [bx] .A4ExifDSIo.ChanLibHandle, dx mov cx, al ; loRequestReset takes xchg bx, dx ;the device handle in IoRequestReset 7BX and the channel xchg bx, dx ;handle in CX xor ax, ax call StartTheChannelRunning ReturnCLc: cle ret ProcEnd if Asic9

ProcBegin@ A4ExifTickInt, far

This function is called by the tick handler on every tick of

; the system clock. This happens 32 times a second.

; The operating system will call a device driver to hold when memory is ; being moved and when the machine is being powered down. It will not

; call the device driver when the pack doors are opened.

Opening the pack doors will cause power to the peripheral to be cut,

; ; and therefore the driver needs to be held in the way it would be if ; the machine powered down. Only for Asic9 based machines. ; This function checks the state of the doors on every tick and calls iH Hold and resume when it sees the status of the doors change. H IN: ; The state of the door in SI ; OUT: ; Nothing ; cmp si, DoorOpen 7Is the door open je TheDoorIsOpen 7or closed? cmp HoldFlag, 2 7Closed Door, HoldFlag=2 je NeedToDoTheResume ;means we do a resume ret 7Closed Door, HoldFlag!=2 NeedToDoTheHold: mov HoldFlag, 2 jmp A4HoldFromTick NeedToDoTheResume: mov HoldFlag, 0 jmp A4ResumeFromTick TheDoorIsOpen: xor ax, ax cmp HoldFlag, al je NeedToDoTheHold ret ProcEnd noret endif ProcBegin@ A4ExifHandler, far ; ; When an application is waiting within an iowait and a signal is ; generated then before passing that signal to the application the : OS first runs any wait handlers belonging to the device driver ; channels that the application has open. ; The interrupt routine can generate a signal but cannot fill in any ; status words or pass values back to the application because the ; applications DS space is not available. The handler can consume a ; signal generated by an interrupt and then fill any status words 7 before re-signalling the application. A handler always has access ; to the application's DS space. The wait handler can consume the 7 signal which is then no longer passed back to the application. Hi IN:

Revision 1.00 Page 92 of 115 pages

The Psion SIBO Hardware Development Kit

Ne Ne Ne Ne

Psion PLC (c) May 1995

Pointer to our control block in applications DS space in BX DS,ES,SS point at application's data space

OUT: Carry clear - do not consume the signal, signal not for us 7 Carry set - consume the signal, re-enable handler if AL ; non-zero else don't re-enable handler if AL=0. 7 cld pushf cli mov di, [bx].A4ExifDSStatusEntPtr ;Is the signal for us? cmp cs: [di] .A4ExifCSChanReadCompleted, 1 jne ExitHandlerSignalNotForuUs ;If it is, copy mov cs: [di] .A4ExifCSChanReadCompleted, 0 ;the values read in mov al, cs: [di] .A4ExifCSA1Value ;the interrupt mov ah, cs: [di] .A4ExifCSA2Value ;routine back to mov di, [bx].A4ExifDSA1Ptr ;the application mov [di], al ;Asynchronous read mov di, [bx].A4ExifDSA2Ptr ;has been completed mov [di], ah xor di, di xchg [bx] .A4ExifDSStatusPtr, di ;Clear the status mov word ptr [di], 0 ;word popft ToSignal xor ax, ax stc ;STC and AL!=0 => ret ;consume signal and ExitHandlerSignalNotForus: ;don't re-enable popft ;handler elec ret ProcEnd StrategyVectorTable label word dw offset A4ExifDefault ;StrategyPanic dw offset A4ExifRead 7 StrategyRead ie P_FREAD dw offset A4ExifWrite ;StrategyWrite ie P_FWRITE dw offset A4ExifClose ;StrategyClose ie P_FCLOSE dw offset A4ExifCancel 7 StrategyCancel ie P_FCANCEL dw offset A4ExifDefault ;StrategyAttach dw offset A4ExifDefault ;StrategyDetach dw offset A4ExifSet ;StrategySet ie P_FSET dw offset A4ExifSense ;StrategySense ie P_FSENSE ProcBegin@ A4ExifStrategy, far Called by the operating system when an I/O request is made on

the device driver.

Calls to this funcion from an owning application will usually take the form p_ioc(pcb, func, &Stat, &Al, &A2) ;

The strategy function is called with a function number specifying the action which the driver is to take, a status word to fill when the action is complete, and two arguments Al and A2.

Nee Ne Ne

Se ee

All strategy functions must complete with a signal to the application. Functions can be asynchronous and need not complete immediately. IN: Pointer to our control block in the applications DS in BX 7 Device driver handle in DX ; Pointer to the RqEnt struct in SI ; Pointer to a IntEnt struct in BP ; DS,ES,SS point at the applications data space i OUT: ; Returned value in AX ; Must call IoSignal somewhere to signal completion ; of the I/O request. v mov ax, [si].RqFunction ;Get the function number mov dx, [si].RqAlPtr ;DX holds the first argument mov di, [si].RqStatusPtr ;for convenience mov word ptr [di], PendingErr 7Status word holds shl ax, 1 ; E_FILE_PENDING mov di, ax push StrategyVectorTable[di] ;Jump to required function mov di, [bx] .A4ExifDSStatusEntPtr ;with our CS control block retn ;pointer in DI A4ExifDefault: ToRoot

Revision 1.00

Page 93 of 115 pages

The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

ret ExitWithCompletionStatusZero:

xor ax, ax ;Common exit points ExitWithOtherCompletionStatus:

mov di, [si].RqStatusPtr

mov word ptr [di], ax

ToSignal ExitStillPending:

xOr ax, ax

cle

ret

ProcEnd noret

STRATEGY VECTOR TABLE FUNCTIONS

IN: DX holds the pointer to the first argument in 'p_iow(...)' call BX holds the address of the open channel control block CS:DI holds the address of status struc identifying the open channel

See eee Ty

ProcBegin@ A4ExifRead, far

H Strategy vector table function that handles asynchronous byte reads 7 from the LEDs and switches.

i; The corresponding PLIB call is p_ioc(pcb,P_FREAD, &Stat, &Argl, &Arg2) ; ; The request is completed when the interrupt routine signals the

; handler which in turn signals the application passing back the values ; read at the time of the interrupt through the AlPtr and A2Ptr.

H IN:

; Pointer to control block in applications data space in BX

i Pointer to control block in our CS space in DI

; Al (pointer to Argl) in DX

,

v

OUT: Jumps to common exit point . Panics if multiple requests , cmp [bx] .A4ExifDSStatusPtr, 0 ;Panic if we already jne PanicPending ;have an I/O read request pushf ;pending on the channel cli ;Disable interrupts mov cs: [di] .A4ExifCSChanReadCompleted, 2 mov ax, [si].RqA1Ptr mov [bx] .A4ExifDSA1Ptr, ax ; Store the locations to mov ax, [si].RqA2Ptr ;put the data when we get it mov [bx] .A4ExifDSA2Ptr, ax mov di, [si].RqStatusPtr mov [bx] .A4ExifDSStatusPtr, di ;DI holds the address mov word ptr [di], PendingErr 7of status word and we popf ;Signal that we are waiting mov bx, [bx] .A4ExifDSHandlerPtr ;for completion of read mov cl, ToEnableHandler ;Enable Wait Handler jmp short ExitStillPending 7No IoSignal because PanicPending: ;we are still waiting mov al, PaniclIoPending ProcPanic

ProcEnd noret

ProcBegin@ A4ExifWrite, far

This function sets the state of the LEDs.

It completes immediately after setting the state as it has nothing to wait for.

Write is the same as set.

Ne Ne Ne Ne Ne te

IN: ; Pointer to control block in applications data space in BX ; Pointer to control block in our CS space in DI . Al in DX - OUT: - Jumps to Set , jmp WriteAndSetAreTheSame

ProcEnd noret

ProcBegin@ A4ExifClose, far

Revision 1.00 Page 94 of 115 pages

The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

Handles the request to close a channel. called by the PLIB call p_iow(pcb,P_FCLOSE) or p_close (pcb)

Ne Ne Ne Ne

IN: Pointer to control block in applications data space in BX ; Pointer to control block in our CS space in DI ; OUT: ; Jumps to common exit point , call StopTheChannelRunning 7Stop interrupts if Asic9 push bx ;Close down the mov bx, cs: [di] .A4ExifCSTickHandle 7;"TCK:" channel IoClose pop bx endif push bx mov ax, [bx] .A4ExifDSIo.ChanLibHandle ;Remove the wait push ax ;handler mov bx, [bx] .A4ExifDSHandlerPtr IoRemoveHandler cmp cs: [di] .A4ExifCSChanReadCompleted, 0 ;If the interrupt je NoSignalToConsumeFromInterrupt ;has signalled the ToWaitForSignal ;handler we need to NoSignalToConsumeFromInterrupt: ;consume its signal pop bx ;now the handler mov cx, di ;has been removed ToRequestResetCancel pop bx 7No longer need reset HeapFreeCell ;Free our control mov al, cs: [di] .-A4ExifCSChannelIntMask ;block in app's DS HwFreeChannel mov cs: [di] .A4ExifCSChannelOpen, 0 jmp ExitWithCompletionStatusZero 7To signal completion ProcEnd noret 7,of close request ProcBegin@ A4ExifCancel, far v ; Cancel any pending asynchronous read. ; Called by the PLIB function p_iow(pcb,P_FCANCEL) ; i In: ; Pointer to control block in applications data space in BX ; Pointer to control block in our CS space in DI ; Out: ; Jumps to common exit point 7 pushf cli cmp [bx] .A4ExifDSStatusPtr, 0 ;Check that there is je NothingToCancel ya request pending push bx mov bx, [bx] .A4ExifDSHandlerPtr sub cl ol ToEnableHandler ;Disable Wait Handler pop bx cmp cs: [di] .A4ExifCSChanReadCompleted, 1 jne NoSignalFromInterrupt ;TO consume any stray ToWaitForSignal ;Signal from the NoSignalFromInterrupt: ;interrupt routine mov cs: [di] .A4ExifCSChanReadCompleted, 0 xor fomcramre be ;To signal completion xchg di, [bx].A4ExifDSStatusPtr ;of the outstanding mov word ptr [di], CancelErr pasync read request ToSignal ;Signal to p_waitstat NothingToCancel: popft jmp ExitWithCompletionStatusZero 7To signal completion ProcEnd noret 7of the cancel request ProcBegin@ A4ExifSet, far , 7 Write a value to the LED latch. ; Can be called by the PLIB call p_iow(pcb,P_FSET, &Argl); where Al ; is an unsigned byte. ; Write is the same as set. 7 IN: ; Pointer to control block in applications data space in BX 7 Pointer to control block in our CS space in DI 7 Al (pointer to Argl) in DX

Revision 1.00 Page 95 of 115 pages

The Psion SIBO Hardware Development Kit

OUT: Jumps to common exit point

, WriteAndSetAreTheSame:

Steere Ty

Ne Ne Ne Ne

seo

pushf

cli

mov al, cs: [di] .-A4ExifCSChannelSelect HwSelectChannel

push ax

mov bx, dx

mov dl, U50UTPUT_LATCH

mov al, [bx]

call OutputByte

pop ax

HwSelectChannel

popft

jmp ExitWithCompletionStatusZero

ProcEnd noret

ProcBegin@ A4ExifSense, far

Reads the state of the LEDS and Switches.

Psion PLC (c) May 1995

7Select our SIBO ; serial channel 7Store old channel

;DX (now BX) points ;to the value to output to our ;peripheral

;Return old channel

;To signal completion

7of set request

Can be called from PLIB using p_iow(pcb, P_FSENSE, éArgl, &Arg2)

Where Argl and Arg2 are unsigned bytes. In:

Pointer to control block in applications data space in BX Pointer to control block in our CS space in DI

Al (pointer to Argl) in DX

Out: Jumps to common exit point pushf cli mov al, cs: [di] .-A4ExifCSChannelSelect HwSelectChannel push ax mov bx, dx mov dl, U4STATUS_BUFFER call InputByte mov [bx], al mov bx, [si] .RqA2Ptr mov dl, U3INPUT_BUFFER call InputByte mov [bx], al pop ax HwSelectChannel popft jmp ExitWithCompletionStatusZero

ProcEnd noret

LOCAL DEVICE DRIVER FUNCTIONS

7Select our SIBO ;serial channel 7 Store old channel

;DX (now BX) points ;to the variable in ;which to place the ;value read from U4. 7BX now points to

;the variable in

;which to place the ;value read from U3.

;Return old channel

;To signal completion

;of a sense request

Interrupts must be off prior to the call to this function.

IN:

DL has address to which Asic4 is to write

AL holds the value to output

mov al, (SerialWriteSingle or A4Address)

SBUSY SCONTOUT mov al, dl SBUSY SDATAOUT mov al, (SerialReadSingle or A4Data) SBUSY

SCONTOUT

SBUSY

SDATAIN

ret

ProcEnd noret

ProcBegin@ OutputByte

Interrupts must be off prior to the call to this function.

Revision 1.00

Page 96 of 115 pages

The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

H IN: ; DL has address to which Asic4 is to write ; AL has the value to output

mov al, (SerialWriteSingle or A4Address)

mov al, dl

mov al, (SerialWriteSingle or A4Data) SBUSY SCONTOUT SBUSY XNOP pop ax SDATAOUT ret ProcEnd noret

ProcBegin@ IntVecO, far

- Interrupt on serial channel0 3 Calls Comint with channel control block pointer in DI ,

mov di, offset Channel0O

jmp ComIint

ProcEnd noret

if Corporate or S3c ProcBegin@ IntVecl1, far

Sat

Interrupt on serial channell

; Calls Comint with channel control block pointer in DI ,

mov di, offset Channell

jmp ComInt

ProcEnd noret

ProcBegin@ IntVec2,far

Interrupt on serial channel2 Calls Comint with channel control block pointer in DI

Ne Ne Ne Ne

mov di, offset Channel2 7 FALL THROUGH ProcEnd noret endif ProcBegin@ ComInt, far , ; The common interrupt service routine code. ; When an interrupt occurs, the first task is to read the status 7 buffer of latch U4. The subsequent action is dependent on the ; postion of switches Sl and S2. For the purposes of this example, ; the four posibilities for the switch values correspond somewhat ; arbitrarily to four different byte values that are written to U5. ; in the 8086, interrupts cannot occur while in an interrupt routine. ; If an asynchronous read is pending then the handler is signalled. 7 IN: ; Channel's CS based control block pointer in DI , cmp cs: [di] .A4ExifCSChanReadCompleted, 2 ;Only if 2 do we have jne NotAsynchronousRead ;asynch read completed mov cs: [di] .A4ExifCSChanReadCompleted, 1 mov bx, cs: [di] .A4ExifCSProcessId ;Signals completion ToSignalByPidNoReSched 7Of read to OS so as NotAsynchronousRead: ;to invoke handler mov al, cs: [di] .-A4ExifCSChannelSelect HwSelectChannel push ax mov dl, U3INPUT_BUFFER call InputByte mov cs: [di] .A4ExifCSA2Value, al ;LED byte mov dl, U4STATUS_BUFFER

Revision 1.00 Page 97 of 115 pages

The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

call InputByte mov cs: [di] .A4ExifCSAlValue, al ; Status byte and al, INTERRUPT_STATUS_MASK xchg al, SwitchStatus cmp SwitchStatus, S2S3_ON 7;S2 and S3 on => turn je A11LEDsOn 7on alternate LEDs cmp SwitchStatus, S2S3_OFF 7S2 and S3 off => not je A11LEDsOff ;the alternate LEDs cmp SwitchStatus, S2_ONLY 782 on, S3 off => turn je TopLEDsOn 7on top four LEDs cmp SwitchStatus, S3_ONLY 753 on, S2 off => turn je BottomLEDsOn 7on bottom four LEDs ErroriInSwitchStatusByte: jmp ClearInterruptAndReschedule A11LEDsOn: mov al, SOME_LEDS_ON jmp Output LEDByte A11LEDsOff: mov al, SOME_LEDS_OFF jmp Output LEDByte TopLEDsOn: mov al, TOP_LEDS_ON jmp Output LEDByte BottomLEDsOn: mov al, BOTTOM_LEDS_ON OutputLEDByte: mov dl, US50UTPUT_LATCH call OutputByte ClearInterruptAndReschedule: mov dl, INTERRUPT_LATCH call OutputByte if Asic9 ;A write to this location out A9BNonSpecificEoiw, al ;informs the interrupt else ;controller that the out AlNonSpecificEoi, al ;installed interrupt endif ;service routine has pop ax ; finished HwSelectChannel onlkres ;Reschedule if necessary ret ProcEnd noret ProcBegin@ StartInterrupts po SSS SES ; Start interrupts assuming interrupts are ; off prior to call. ; The EPOC GenSetRevector service loads in ; a user-specified interrupt service routine ; located at the address given in cx:bx ; (segment cx, offset bx) for the interrupt ; vector number given in AL. Note that the 7 variable A4ExifCSChannelIntVec holds the ; name of the appropriate required interrupt ; vector routine for the channel. H IN: ; Our CS control block pointer in DI H OUT: i; Nothing is mov al, cs: [di] .-A4ExifCSChannelIntNum 7Get the OS to call mov cx, CS ;the function in push bx 7CS:BX every time mov bx, cs: [di] .A4ExifCSChannelIntVec ;that the interrupt GenSetRevector ;whose number is in pop bx 7;AL occurs ife Asic9 in al, AlInterruptMask or al, cs: [di] .A4ExifCSChannelIntMask ;Set the mask out AlInterruptMask, al ;location so as ; interrupt else ;to enable that in al, A9BInterruptMaskRW ; interrupt or al, cs: [di] .A4ExifCSChannelIntMask out A9BInterruptMaskRW, al endif ret

ProcEnd noret

Revision 1.00 Page 98 of 115 pages

The Psion SIBO Hardware Development Kit

ProcBegin@ StopInterrupts

; Stop interrupts assuming that interrupts are off

The EPOC GenResetRevector OS service

interrupt service routine with the original routine and interrupt mask for the vector given in AL. IN:

Our CS control block pointer in DI

Se ee Te

OUT: ; Nothing

ife Asic9

replaces the previously loaded user-specified

Psion PLC (c) May 1995

in al, AlInterruptMask ;Disable the mov ah, cs: [di] .A4ExifCSChannelIntMask ; interrupt not ah and al, ah out AlInterruptMask, al else in al, A9BInterruptMaskRW mov ah, cs: [di] .A4ExifCSChannelIntMask not ah and al, ah out A9BInterruptMaskRW, al endif mov al, cs: [di] .-A4ExifCSChannelIntNum ;Return the interrupt GenResetRevector ;vector to the OS ret ; default ProcEnd noret ProcBegin@ StartTheChannelRunning Fo eee eeeeeeea= ; Starts the hardware and interrupts going ; If the hardware is aready running then there is nothing to do ; Must check that the hardware has not vanished before restarting it H IN: ; Our CS control block pointer in DI 7 OUT: i Nothing 7 pushf cli cmp byte ptr cs: [di].A4ExifCSChannelRunning, 0 jne ChannelAlreadyRunning call CheckHardwarePresent jc HardwareNotPresent mov al, cs: [di] .-A4ExifCSChannelSelect HwSelectChannel push ax mov al, (SerialWriteSingle or A4Control) ; Switch on the SBUSY output latch U5 SCONTOUT ;by asserting mov al, U5_ENABLE_ON ;the ASIC4 LBO line SBUSY ; (LBO is inverted) SDATAOUT xor ax,ax mov dl, INTERRUPT_LATCH 7Clear any pending call OutputByte ;interrupt on the mov dl, US5OUTPUT_LATCH ;peripheral call OutputByte 7Preset the LEDs pop ax ;to all off HwSelectChannel call StartInterrupts mov cs: [di] .A4ExifCSChannelRunning, 1 ChannelAlreadyRunning: popft cle ret HardwareNotPresent: popft stc ret

ProcEnd noret

ProcBegin@ StopTheChannelRunning

Revision 1.00

Page 99 of 115 pages

The Psion SIBO Hardware Development Kit

Ne Ne Ne Ne

Stops the hardware and interrupts

Psion PLC (c) May 1995

Checks to see if the hardware is really running to start with

IN: Our CS control block pointer in DI

i OUT: ; Nothing 7

pushf

cli

cmp byte ptr cs:[di].A4ExifCSChannelRunning, 0

je ChannelNotRunning

mov al, cs: [di] .-A4ExifCSChannelSelect

HwSelectChannel

push ax

mov al, (SerialWriteSingle or A4Control)

SBUSY

SCONTOUT

mov al, U5_ENABLE_OFF

SBUSY

SDATAOUT

xor ax, ax

mov dl, US50OUTPUT_LATCH

call OutputByte

pop ax

HwSelectChannel

call StopInterrupts

mov cs: [di] .A4ExifCSChannelRunning, 0 ChannelNotRunning:

popft

ret

Se eT

ProcEnd noret

ProcBegin@ CheckHardwarePresent

Used to determine whether the correct hardware is present

on the successfully procured serial channel.

IN:

CS control block pointer in DI OUT:

Carry clear - correct hardware is there

Carry set - wrong or no hardware pushf cli ;Select the correct mov al, cs: [di] .A4ExifCSChannelSelect ;SIBO channel that HwSelectChannel ;the peripheral is push ax ;attached to HwNullFrame mov al, (SerialSelect or Asic4Id) SBUSY ;First look for an SCONTOUT 7;ASIC4 at the other XNOP ;end of the link SBUSY SDATAIN ;Ilf the returned test al,al ;value is non-zero je ConnectionFailedA4NotPresent ;we have an ASIC4 mov al, (SerialReadSingle or A4InfoR) SBUSY ;Now see if we have SCONTOUT ;the right peripheral XNOP 7;XNOP allows the busy SBUSY 7Signal to come SDATAIN ;through for the wait and al, A4PERIPH_MASK cmp al, EXTENDED_INFO_BYTE ;Mask out the bottom jne ConnectionFailed ;four bits as the pop ax yupper four contain HwSelectChannel ;the peripheral ID popft cle ;If it is our hardware ret 7exit with carry clear

ConnectionFailedA4NotPresent:

mov al, (SerialSelect or Asic5Normalld) ;Its not an ASIC4 SBUSY ;peripheral SCONTOUT 7By selecting a non XNOP 7;ASIC4 as an ASIC4, SDATAIN ;we effectively

test al,al

Revision 1.00

;disable whatever is

Page 100 of 115 pages

The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

jne ConnectionFailed yout there so we do mov al, (SerialSelect or Asic5PackId) ja select for all SBUSY ;possibilities so SCONTOUT ;that we don't end XNOP ;up disabling SDATAIN yanything that we

test al,al ;can't control. jne ConnectionFailed

mov al, (SerialSelect or Asic8Id) 7Modem chip id

SBUSY

SCONTOUT

XNOP

SDATAIN ConnectionFailed:

pop ax

HwSelectChannel

popft

stc

ret

ProcEnd noret

EndCodeSeg

stack segment stack para 'data' stack ends

end A4ExifLDD

Revision 1.00 Page 101 of 115 pages

The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

SYSS$AS5.ASM

title ASSPDD Epoc Serial physical device driver for the 16550 subttl Copyright Psion PLC 1993 name SYSSAS5

i VERSION DATE DESCRIPTION

me MEE ee ee ee eee

; Lat 08/12/94 Initial version

7 Written by Jason December 1994

: Serial Driver for Epoc based around ASIC5

Sr5s3 = 0

Sr5S3a = 1

ifdef BUILDS3

Sr5S3 = 1.

Sr5S3a = 0

BUILDHH equ 1

endif

a Sr5S3a

BUILDSB equ 1

endif include ..\inc\epoc.inc include ..\inc\epocser.inc include ..\inc\epoclib.inc include ..\inc\epocsibo.inc include ..\srcs\ossibo.inc include ..\srces\ospack.inc

Sr5ChannelStruct struc

Sr50pen db ? ; Is the channel open SrKSCtY1L db ? ; State of control lines Sr5IntVector db 2 ; The Vector number Sr5Channel db ? ; Which channel are we Sr5Mask db ? ; InterruptMask Sr5Running db ; Are we running Sr5IntRoutineVec dw cs ; Vector to Interrupt Sr5Baud dw ? ; The baud rate Sr5LddData dw ? ; Info from Ldd above Sr5StatusInt dd ? ; Vectors in serial Sr5Recvint dd 2 ; Above to be called Sr5XmitInt dd ? ; On input/output Sr5ClockEnable db ? ; Reason to stop

Sr5TheLines db ? ; State of the modem lines

Sr5ChannelStruct ends

A5Ent struc A5PortA A5PortB A5PortBMode A5PortD A5Swipel A5Swipe2 A5IntMask A5CtrlReg A5USR A5RHR A5BDLSB A5SBDMSB A5MCRIEoi A5MCRPresentEoi A5MCR2Eoi ASDUMMYF

A5Ent ends

Lt Consumer NumberOfChannels else NumberOfChannels endif OsActivityMeter StopTimeOut

S_RS2320N

Revision 1.00

db db db db db db db db

db db

db db db db db db

equ

equ

equ

equ

equ

VVV Vv vw

YN vn vv

158ch 1000

00000001b

at

ASIC5 Read/Write Port A R/W

Port B R/W Inc/Mode

Port CD Write only

Ne Ne Ne Ne Ne

Interrupt mask R/W IntType/Ctrl register UART Status/Ctrl Receive/Transmit

Baud Rate write only Baud Rate write only MCR shift register Barcode data&ints

Ne Ne Ne Ne

; S3 Single Channel , HC,S3C Three Channel

; Activity Channel ; w~ls (1000ms) wait

7 RS232 on

Page 102 of 115 pages

The Psion SIBO Hardware Development Kit

Psion PLC (c) May 1995

S_RSTTLON equ 00000100b ; Line drivers on S_CENTON equ 00010000b ; Line drivers enable S_RXENB equ 00000001b ; Receive interrupt on S_TXENB equ 00000010b ; Transmit interrupt on S_TXEMPTY equ 00010000b ; transmit buffer empty S_RXINT equ 00000001b ; Receive interrupt? S_TXINT equ 00000010b ; transmit interrupt? S_MDINT equ 00000100b ; Modem status interrupt S_CTS equ 00000001b # CLS S_RTS equ 00000010b ; RTS S_DCD equ 00000100b DCD S_DSR equ 00000010b ; DCR S_DTR equ 00000100b ; DIR OVERRUN_ERROR equ 01000000b ; Character overrun PARITY_ERROR equ 10000000b ; Parity error S_PERIPHERALMODE equ 00000011b ; ASIC5 RS232 mode S_UART_OFF equ 00000010b ; ASIC5 peripheral mode dgroup group stack assume ds:dgroup,es:dgroup,ss:dgroup CodeSeg ProcBegin@ OsAS5PDD ; SiS SeSe Sees Ses eceses dw PDDSignature db 'TTY.SR5',0 dw (VectorEnd-Vector) /2 Vector: dw OsAS5SInstall dw OsAS5Remove dw OsAS50Open dw OsAS5Strategy VectorEnd:

BaudRateTable dw

-077f£h, -04£fh, -0368h, -02cch, -027£h, -013fh

dw -009fh, -004fh, -0035h, -0030h, -0027h, -0019h dw -—0013h, -000ch, -0009h, -0004h

DataBitsTable db 0,2,4,6

5,6,7,8 bits per char frame

ParityTable db 08h,18h, 0h, 0h ; Even,Odd,Mark, Space parity Chan0O Sr5ChannelStruct <> Chanl Sr5ChannelStruct <> Chan2 Sr5ChannelStruct <>

if Consumer

if Asic9 SetupTable dw offset AS5Int1l db HwIrq2Revector,mask A9MSlave db SelectChannel5, (mask A9MClockEnable5 shr 8) else SetupTable dw offset AS5Intl db HwIrq4Revector,mask Asic2Int db SelectChannel7, (mask ClockEnable7 shr 8) endif else if Asic9 SetupTable dw offset AS5Int1l db HwIrq4Revector,mask A9MExpIntA db SelectChannel3, (mask A9MClockEnable3 shr 8) dw offset AS5Int2 db HwIrq5Revector,mask A9MExpIntB db SelectChannel4, (mask A9MClockEnable4 shr 8) dw offset ASSInt3 db HwIrq2Revector,mask A9MSlave db SelectChannel5, (mask A9MClockEnable5 shr 8) else SetupTable dw offset AS5Int1l db HwIrq3Revector,mask ExpIntLeftA db ExpChannelLeftA, (mask ClockEnableé shr 8) dw offset AS5Int2 db HwIlrq2Revector,mask ExpIntRightB db ExpChannelRightB, (mask ClockEnable5 shr 8) dw offset AS5Int3 db HwIrq4Revector,mask Asic2Int db SelectChannel7, (mask ClockEnable7 shr 8) endif endif

ProcEnd noret

Revision 1.00

Page 103 of 115 pages

The Psion SIBO Hardware Development Kit

ProcBegin@ OsAS5Install, far

Install the device driver Out: Carry clear -happy to install

cld mov cx, NumberOfChannels mov di, offset Chan0od mov si, offset SetupTable pushf cli push ds mov ax, Cs mov ds, ax ResetAllChannelsLoop: mov di].Sr50pen, 0 lodsw mov di].Sr5IntRoutineVec, ax lodsb mov di].Sr5IntVector, al lodsb mov di].Sr5Mask, al lodsb mov di].Sr5Channel, al lodsb mov di].Sr5ClockEnable, al add di, size Sr5ChannelStruct loop ResetAllChannelsLoop pop ds popft AllChannelsOkay: cle ret

Mee Ne

Ne Ne Ne Ne

GotChan:

Revision

ProcEnd noret

ProcBegin@ OsAS5Remove, far

Remove the device driver Out: Carry clear -happy to remove

~

Ne Ne Ne Ne

Psion PLC (c) May 1995

Clear the channels and set up fixed parameters such

as the interrupt vectors and masks for each channel

Channel not open

Set the interrupt handler to call hich Interrupt

=

Mask for that interrupt

Which Psion serial channel

Baud rate clocking enable

Returns with Carry clear

Carry set -we have an open channel and cant be removed.

xor ax, ax or al, Chan0O.Sr50pen or al, Chanl.Sr50pen or al, Chan2.Sr50pen jz AllChannelsOkay mov ax, InUseErr

stc

ret

ProcEnd noret

ProcBegin@ OsAS5Open, far

Open a serial channel

see

In: SS:SI is a pointer to the open Ent Structure

Out: Carry clear, control block in BX

Carry set, error in AX

cld

mov si, [si] .OpenNamePtr mov al, [sitl] CharToFoldedChar

cmp al, 'A'

jb ErrorInOpen

sub al, ‘'A'

cmp al, NumberOfChannels jae ErrorInOpen

xoOr ah, ah

mov bx, offset Chan0O

cmp al, 1

jb GotChan

mov bx, offset Chan2

ja GotChan

mov bx, offset Chanl

mov al, 1

1.00

If we have a channel Still open then return a can't do error else complete okay

Open the channel Get the channel Make Upper Case Indicator which is Part of the name Should be A,B,C

What Channel are We Openning Pointer to Control Block in bx

Page 104 of 115 pages

The Psion SIBO Hardware Development Kit

xchg al, cs: [bx].Sr50Open cmp al, 0 je OkayToOpen CantOpen: mov ax, InUseErr CantOpenDiffErr: stc ret ErroriInOpen: mov ax, NameErr stc ret OkayToOpen: xor al, al mov cs: [bx].Sr5Running, al mov cs: [bx].Sr5TheLines, al mov cs: [bx].Sr5Ctrl, al mov al, cs: [bx].Sr5Mask HwGetChannel jc CantOpenSoClose call CheckHardwarePresent jne OpenedOkay mov al, cs: [bx].Sr5Mask HwF reeChannel CantOpenSoClose: mov cs: [bx].Sr50pen, 0 mov ax, DeviceErr jmp short CantOpenDiffErr OpenedOkay: xor ax, ax ret

ProcEnd noret

AS5StrategyJumpTable label word

dw offset AS50Open

dw offset AS5Close

dw offset AS5Start channel

dw offset AS5Stop

dw offset AS5Set

dw offset AS5Sense

dw offset AS5Control

dw offset ASS5Enquire

dw offset AS5Enable

dw offset AS5SetHandlerCs

ProcBegin@ OsAS5Strategy, far

Strategy functions entry point

Psion PLC (c) May 1995

7 Now try to Open ; That channel

; Check that we have ; The right Hardware

Return with the Offset of our Control Block In bx

Ne Ne Ne Ne

; Load Handler offsets ; Close the channel ; Start the

7 Stop the channel ; Does nothing ; Returns chan status ; Drive the lines ; Returns baud rate ; Begin Output ; Get Handler segments

In: vector number in AX + various data in other registers

; Select the correct

; Output channel Then Call the right Function to deal

; With the strategy

7; request

; Interrupts off ;, and flags are on ; the stack

7 7 Warning! This can be called from within Interrupt 7 iH DS is OsDataGroup (and MUST be preserved) ; Out: DI is pointer to control block H Old channel and flags on stack

cld

mov bx, sp

mov bx, ss: [bx+4]

mov bl, cs: [bx].Sr5Channel

xchg bx, ax

pushf

cli

HwSelectChannel

mov ah, bh

xOr bh, bh

push ax

mov ax, di

mov di, sp

mov di, ss: [dit+8]

jmp AS5StrategyJumpTable [bx]

ProcEnd noret

ProcBegin@ AS5Open, far

; Old channel and flags on the stack, mov cs: [di].Sr5LddData, cx mov word ptr cs: [di].Sr5StatusInt,

Revision 1.00

interrupts off

; Load the offsets of

ax ; the data send and

Page 105 of 115 pages

The Psion SIBO Hardware Development Kit

if

else

endif

mov word ptr cs:[di].Sr5RecvInt, si mov word ptr cs:[di].Sr5XmitInt, dx xor ax, ax

pop ax

HwSelectChannel

popft

ret

ProcEnd noret

ProcBegin@ AS5Close, far

Old channel and flags on the stack,

and cs:[di].Sr50Open, 0 mov al, cs: [di].Sr5Mask HwF reeChannel

pop ax

HwSelectChannel

popft

ret

ProcEnd noret

ProcBegin@ AS5Start, far

Old channel and flags on the stack,

call CheckHardwareFromStart

mov dx, 0

je CantStartSomethingWhichIsntThere Asic9

in ax, AQWControlExtraRW

or ah, cs: [di].Sr5ClockEnable

out A9QWControlExtraRW, ax

mov al, cs: [di].Sr5ClockEnable HwSetA2Control2Bits

mov al, SerialWriteSingle or A5USR SBUSY

SCONTOUT

mov al, cs: [di].Sr5Ctrl

SBUSY

SDATAOUT

mov al, SerialWriteSingle or A5BDLSB SBUSY

SCONTOUT

mov al, byte ptr cs: [di].Sr5Baud SBUSY

SDATAOUT

mov al, SerialWriteSingle or A5BDMSB SBUSY

SCONTOUT

mov al, byte ptr cs: [dit+1].Sr5Baud SBUSY

SDATAOUT

call Get TheInterrupt

xor CX), Cx

call DriveRts

mov al, SerialWriteSingle or A5CtrlReg SBUSY

SCONTOUT

mov al, (S_CENTON or S_RS2320N or SBUSY

SDATAOUT

mov cx, 8 ; 8 ms

pop dx

call WaitTimer

push dx

mov ah, (S_RXENB or S_TXENB or S_MDINT) call EnableTheInterrupt

mov cs:[di].Sr5Running, 1

mov bx, Asic5SerialCurrent HwSetPCurrent

call Status

Revision 1.00

interrupts

Psion PLC (c) May 1995

; veceive routines in ; the Ldd above us ; DX=0 —-We don't support 7; power management ; Return the old ; Channel

interrupts off

; Close the Channel

; Free up our channel ; And the Hardware

; Channel

; Return the old

; channel

off

; Start the S3s clock ; Generator

; Set the baud rate ; and other ; Characteristics

Get the interrupt and clear down

the RTS line (DTR stays at the state ; it was set)

S_RSTTLON)

; Switch on the line ; QGrivers and wait ; for them to power up

; Start all interrupts

Page 106 of 115 pages

The Psion SIBO Hardware Development Kit

CantStartSomethingWhichIsntThere:

pop ax HwSelectChannel popft ret

ProcEnd noret

ProcBegin@ AS5Stop, far

Psion PLC (c) May 1995

; Return the old ; Channel

; Old channel and flags on the stack, interrupts off xor CX, CX ; Clear the state of call DriveRts ; the modem lines mov al, SerialReadSingle or A5IntMask ; Stop all of the SBUSY ; interrupts SCONTOUT XNOP SBUSY SDATAIN and al, not (S_TXENB or S_RXENB or S_MDINT) mov ah, al mov al, SerialWriteSingle or A5IntMask SBUSY SCONTOUT mov al, ah SBUSY SDATAOUT pop ax cmp dh, DevHoldPowerFail je Dont StopHardware cmp cs:[di].Sr5Running, 1 jne DontWait mov cx, StopTimeOut jmp short CompareNow WaitForEmpty: call TickTimer CompareNow: mov al, SerialReadSingle or A5USR SBUSY SCONTOUT XNOP SBUSY SDATAIN test al, S_TXEMPTY loopne WaitForEmpty DontWait: cmp bh, DevHoldNormal je Dont StopHardware if Asic9 mov cl, cs: [di].Sr5ClockEnable ; Turn off baud rate not cl ; Clocking from the in ax, A9WControlExtraRW } S3y3a and ah, cl out A9WControlExtraRW, ax else mov al, cs: [di].Sr5ClockEnable HwClearA2Control2Bits endif mov al, SerialWriteSingle or A5CtrlReg ; Stop the drivers SBUSY , and stuff SCONTOUT sub al, al ; Clear S_CENTON, SBUSY 7 S_RS2320N, S_RSTTLON SDATAOUT Dont StopHardware: mov al, dl ; Return the old HwSelectChannel ; Channel popft xor bx, bx HwSetPCurrent ret ProcEnd noret ProcBegin@ AS5Set, far ; Se SeSeees ees Sees ; Old channel and flags on the stack, interrupts off

Revision 1.00

Page 107 of 115 pages

The Psion SIBO Hardware Development Kit

; In: Information required is on the stack pop ax HwSelectChannel popft mov ah, ss:[si].SerialCharTbaud cmp ah, ss: [si] .SerialCharRbaud jnz ErrorInSet cmp ah, P_BAUD_50 jb ErroriInSet cmp ah, P_BAUD_19200 ja ErroriInSet Got TheSpecialBaud: dec ah mov cl, ss:[si].SerialCharFrame mov al, ss:[si].SerialCharParity dec al xor ch, ch push bx test cl, P_TWOSTOP jz OnlyOneStopBit or ch, 020h OnlyOneStopBit: test cl, P_PARITY jz NoParity mov bx, offset ParityTable xlat cs: [ParityTable] or ch, al NoParity: mov bx, offset DataBitsTable and cl, P_DATA_FRM mov al, cl xlat cs: [DataBitsTable] Or ch, al mov bx, offset BaudRateTable mov al, ah xOr ah, ah shl ax, 1 add bx, ax mov ax, cs: [bx] pop bx mov es? [dt] .Sractrl; ch mov cs:[di].Sr5Baud, ax xOr al, al ret ErroriInSet: mov al, NotSupportedErr stc ret

ProcEnd noret

ProcBegin@ AS5Sense, far

seo

~

Psion PLC (c) May 1995

Return the old channel

Set the Recieve, Transmit characteristics First set the Baud

Rate

Then the number of Stop bits

The Parity

And finally the Number of data bits Per frame

; Old channel and flags on the stack, interrupts off ; Out: The state of the DCD,CTS,DSR lines returned in DX call Status pop ax ; Return the old HwSelectChannel ; Channel popft ret

ProcEnd noret

ProcBegin@ Status

i Out: State of modem lines in DX mov al, SerialReadSingle or A5USR SBUSY SCONTOUT XNOP SBUSY SDATAIN and al, (S_CTS or S_DSR or S_DCD) xor al, (S_CTS or S_DSR or S_DCD) xOr ah, ah

Revision 1.00

see

Get the current Modem status Lines and return With the result In dx

Get the lines we want Invert signals

Page 108 of 115 pages

The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

mov ax, ax ret ProcEnd noret

ProcBegin@ AS5Control, far

; Old channel and flags on the stack, interrupts off

7 In: Lines to drive and state to drive them in DX mov onl emo ie ; Set the state of one test dh, P_SRCTRL_DTR ; of the modem Lines jz DriveRtsNow ; DH is the line to call DriveDtr ; Drive and DL is the pop ax ; Stateto drive it to HwSelectChannel ; Return the old popft ; channel ret

DriveRtsNow: call DriveRts pop ax ; Return the old HwSelectChannel ; channel popft ret

ProcEnd noret

ProcBegin@ DriveDtr

mov ah, S_DTR ; Set/Reset the DTR jmp short DriveTheLine ; Line ProcEnd noret

ProcBegin@ DriveRts

mov ah, S_RTS ; Set/Reset RTS DriveTheLine: mov al, SerialWriteSingle or A5PortD ; Common code to set SBUSY ; and reset either SCONTOUT ; line while mov al, cs:[di].Sr5TheLines ; preserving the test cl, cl ; states of the other IZ ClearLine ; lines or al, ah jmp DoTheOutput ClearLine: not ah and al, ah DoTheOutput: mov cs:[di].Sr5TheLines, al SBUSY SDATAOUT ret

ProcEnd noret

ProcBegin@ AS5Enquire, far

7 Old channel and flags on the stack, interrupts off - Out: DX,AX are the supported baud rates AX for 50 to 19200 DX for above ; CX says what data bits, parity, etc we support pop ax ; Return the old HwSelectChannel ; Channel popf if Asic9 mov ax, —-1 else mov ax, O7fffh endif xor dx, ax mov cx, (Offffh AND (NOT (P_SRINQ_SPLIT OR P_SRINQ_PARSPACE OR P_SRINQ_PARMARK) ) ) ret

ProcEnd noret

ProcBegin@ AS5Enable, far

Revision 1.00 Page 109 of 115 pages

The Psion SIBO Hardware Development Kit

Psion PLC (c) May 1995

- Old channel and flags on the stack, interrupts off mov ah, S_TXENB ; Begin Output by call EnableTheInterrupt ; enabling transmit pop ax ; interrupts HwSelectChannel ; Return the old popft ; channel ret

ProcEnd noret

ProcBegin@ AS5SetHandlerCs, far

CX is CS of above LDD

sew

mov word ptr cs: [di]. (Sr5StatusInt+2), cx mov word ptr cs:[di].(Sr5RecvInt+2), cx mov word ptr cs: [di]. (Sr5XmitInt+2), cx pop ax

HwSelectChannel

popft

ret

ProcEnd noret

ProcBegin@ AS5Int3, far

mov di, offset Chan2 mov ax, PortCActive jmp ComInt

ProcEnd noret

ProcBegin@ AS5Int2,far

mov di, offset Chanl mov ax, PortBActive jmp ComIint

ProcEnd noret

ProcBegin@ AS5Int1,far

mov di,offset Chan0 mov ax, PortAActive 4 FALL THROUGH

ProcEnd noret

ProcBegin@ ComInt, far

The common interrupt handler DS points to OS data space DI is our control block

Mee Ne

; AX is the Active channel ab S3b or S3c

or ds: [OsActivityMeter], ax endif

mov al, cs: [di].Sr5Channel

HwSelectChannel

push ax

mov bx, cs: [di].Sr5LddData TheInterruptLoop:

mov al, SerialReadSingle or A5CtrlReg

SBUSY

SCONTOUT

XNOP

SBUSY

SDATAIN

test al, al

je NothingToDo HaveWeGotAModemStatusLineInterrupt:

test al, S_MDINT

4z HaveWeGotARecievelInterrupt

mov al, SerialReadSingle or A5USR

SBUSY

SCONTOUT

Revision 1.00

~

Mee Ne

Old channel and flags on the stack, interrupts off

; Load the Segment

; Within which the The Ldd above us Return the old channel

; Resides

Channel 3 interrupt vector Jumps to Comint

see

~

Channel 2 interrupt vector Jumps to Comint

seo

~

Channel 1 interrupt 7; vector

; Falls through

7 to Comint

; Set active state

; Select our ; Channel

; Data for LDD above ; in bx

; Find out what

; caused the

; interrupt

Page 110 of 115 pages

The Psion SIBO Hardware Development Kit

Psion PLC (c) May 1995

; Something has been ; recieved in error

; Establish the error

; Get the character ; in question

; invert signals

XNOP SBUSY SDATAIN test al, (OVERRUN_ERROR or PARITY_ERROR) jz ModemStatusInterruptOnly push ax mov ah, SERPARITY_ERR test al, PARITY_ERROR jnz IsAParityError mov ah, SEROVERRUN_ERR IsAParityError: mov al, SerialReadSingle or A5RHR SBUSY SCONTOUT XNOP SBUSY SDATAIN push di call dword ptr cs: [di] .Sr5RecvInt pop di pop ax ModemStatusInterruptOnly: and ax, (S_CTS or S_DSR or S_DCD) xor al, (S_CTS or S_DSR or S_DCD) mov ax, ax push di call dword ptr cs: [di].Sr5StatusInt pop di jmp short TheInterruptLoop

HaveWeGotARecievelInterrupt:

; AX has character received

Resced if neccessary

; Gisable TX interrupts

test al, S_RXINT jz HaveWeGotATransmitInterrupt mov al, SerialReadSingle or A5RHR SBUSY SCONTOUT XNOP SBUSY SDATAIN xOr ah, ah push di call dword ptr cs: [di] .Sr5RecvInt pop di jmp short TheInterruptLoop HaveWeGotATransmitInterrupt: test al, S_TXINT jz NothingToDo push di call dword ptr cs: [di] .Sr5XmitInt pop di test ax, ax ; —-l1 if disable js DisableTransmitInts mov ah, al mov al, SerialWriteSingle or A5RHR SBUSY SCONTOUT mov al, ah SBUSY SDATAOUT jmp TheInterrupt Loop NothingToDo: if Asic9 out A9BNonSpecificEoiwW, al else out AlNonSpecificEoi, al endif pop ax HwSelectChannel cle ; ret DisableTransmitInts: mov al, SerialReadSingle or A5IntMask SBUSY SCONTOUT XNOP SBUSY SDATAIN and al, not S_TXENB mov ah, al mov al, SerialWriteSingle or A5IntMask SBUSY

Revision 1.00

Page 111 of 115 pages

The Psion SIBO Hardware Development Kit

SCONTOUT mov SBUSY SDATAOUT jmp TheInterrupt Loop ProcEnd noret

al, ah

ProcBegin@ GetTheInterrupt

mov al, cs:[di].Sr5IntVector H mov Cx, CS F mov bx, cs:[di].Sr5IntRoutineVec ; GenSetRevector A ret ,

ProcEnd noret

ProcBegin@ EnableTheInterrupt

mov al, SerialReadSingle or A5IntMask SBUSY SCONTOUT XNOP SBUSY SDATAIN or ah, al mov al, SerialWriteSingle or A5IntMask SBUSY SCONTOUT mov al, ah SBUSY SDATAOUT if Asic9 in al, A9BInterruptMaskRW ; or al, cs: [di].Sr5Mask ; out A9BInterruptMaskRwW, al else in al, AlInterruptMask or al, cs: [di] .Sr5Mask out AlInterruptMask, al endif ret ProcEnd noret ProcBegin@ StopInterrupts ; StessSeSesee—e-Seeeseeese mov al, SerialReadSingle or A5IntMask H SBUSY ; SCONTOUT XNOP SBUSY SDATAIN and al, not (S_RXENB or S_TXENB or S_MDINT) mov ah, al mov al, SerialWriteSingle or A5IntMask SBUSY SCONTOUT mov al, ah SBUSY SDATAOUT mov ah, cs: [di].Sr5Mask not ah if Asic9 in al, A9BInterruptMaskRW ; and al,ah ; out A9BInterruptMaskRW, al ; else ; in al, AlInterruptMask and al,ah out AlInterruptMask, al endif mov al, cs:[di].Sr5IntVector GenResetRevector ret

Revision 1.00

Psion PLC (c) May 1995

Load the address of the appropriate interrupt routine into the correct vector

Set the mask to enable Interrupts

Stop interrupts from Asic5

Stop Interrupts By clearing the

Mask and resetting The Vector

Page 112 of 115 pages

The Psion SIBO Hardware Development Kit

ProcEnd noret

ProcBegin@ CheckHardwarePresent

mov al, cs: [bx] .Sr5Channel HwSelectChannel HwNullFrame mov al, (SerialSelect or Asic5Normalld) SBUSY SCONTOUT XNOP SBUSY SDATAIN test al,al je ConnectionFailed GotConnection: popft ous) ret ConnectionFailed: mov al, SBUSY SCONTOUT XNOP SBUSY SDATAIN test jne mov SBUSY SCONTOUT XNOP SBUSY SDATAIN test jne mov SBUSY SCONTOUT XNOP SBUSY SDATAIN ConnectionFailedExit: popft stc ret ProcEnd noret

SerialSelect or Asic4Id

al, al ConnectionFailedExit al, SerialSelect or Asic8Id

al, al ConnectionFailedExit al, SerialSelect or Asic5PackId

ProcBegin@ CheckHardwareFromStart

pushf

HwNullFrame

mov al, (SerialSelect or Asic5Normalld) SBUSY

SCONTOUT

XNOP

SBUSY

SDATAIN

test al,al

je ConnectionFailed

test al, mask A5MultiDrop

jne ConnectionFailedExit

popft mov SBUSY SCONTOUT mov SBUSY SDATAOUT cle

ret ProcEnd noret

al,

al, S_PERIPHERALMODE

ProcBegin@ WaitTimer

Revision 1.00

SerialWriteSingle or A5PortBMode

Ne Ne Ne Ne te

Ne Ne Ne Ne Ne

Psion PLC (c) May 1995

Check that the ; Harware is there

And that it is what It should be

First look for An ASIC4 at the other End of the link

Asic4 Id

Modem chip Id

Asic5Spack Id

Check that the Harware is there First look for An ASIC5 at the other End of the link

If not a 3link or if in multidrop mode then we are in trouble

Put the 3Link in peripheral mode

Page 113 of 115 pages

The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

In: CX number of ms to wait for Channel store in DL Out: Channel store in DL

Wait for a given

inc cx i

WaitTickLoop: ; Number of ms call TickTimer ; Plus one to guarantee loop WaitTickLoop ; That at least cx ms ret 7 Go by ProcEnd

WaiterLoop:

stack stack

ProcBegin@ TickTimer

Uses writes down our channel to simulate tick timer waits

Must allow interrupts so other things can run -we will be here for 1/1000 of a second and may be called many times ChannelStore in/out in DL

mov al, dl ; Return the old HwSelectChannel ; Channel

mov ah, al pushf

sez

push Cx

mov cx, 12 ims

128 frames =1lms

pushf about 12 times

cli 7 round the loop

out ResetWatchDog, al

mov al, ah

HwSelectChannel

mov dl, al ; Get Correct channel mov al, (SerialWriteSingle or 0) Do a write to

SBUSY nowhere and

SCONTOUT waste some time

See Ne

See Ne

SCONTOUT ; Do it eight times

SBUSY SCONTOUT SBUSY mov al, dl HwSelectChannel mov ah, al popft

loop WaiterLoop pop CX

popft

mov al, ah HwSelectChannel mov dl, al ret

ProcEnd

Return the old channel

EndCodeSeg

segment stack para 'data' ends

end OsAS5PDD

Revision 1.00 Page 114 of 115 pages

The Psion SIBO Hardware Development Kit Psion PLC (c) May 1995

Assembler Macros

Excerpts from the include file ossibo.inc.

if ASIC1 SCONTOUT macro out A2SerialControl, al endm SDATAOUT macro out A2SerialData, al endm SBUSY macro wait endm SREAD macro _REG mov al, SerialReadSingle or _REG out A2SerialControl, al nop SBUSY in al, A2SerialData endm SREADM macro _REG mov al, SerialReadMulti or _REG out A2SerialControl, al nop SBUSY in al, A2SerialData endm SWRITE macro _REG,_VAL mov al, SerialWriteSingle or _REG out A2SerialControl, al SBUSY mov al, _VAL out A2SerialData, al endm SWRITEM macro _REG,_VAL mov al, SerialWriteMulti, _REG out A2SerialControl, al SBUSY mov al, _VAL out A2SerialData, al endm endif ach ASIC9 SCONTOUT macro out A9BSerialControlW, al endm SDATAOUT macro out A9BSerialDataRW, al endm SDATAIN macro in al, A9BSerialDataRW endm SBUSY macro endm SREAD macro _REG mov al, SerialReadSingle or _REG out A9BSerialControlwW, al in al, A9BSerialDataRW endm SREADM macro _REG mov al, SerialReadMulti or _REG out A9BSerialControlwW, al in al, A9BSerialDataRW endm SWRITE macro _REG,_VAL mov al, SerialWriteSingle or _REG out A9BSerialControlwW, al mov al, _VAL out A9BSerialDataRW, al endm SWRITEM macro _REG,_VAL mov al, SerialWriteMulti or _REG out A9BSerialControlwW, al mov al, _VAL out A9BSerialDataRW, al endm endif

Revision 1.00 Page 115 of 115 pages